Summary of Adel Software Manufacturing Architecture Framework (ASMAF)
There are numerous enterprise architecture frameworks (EAF) in the software development ecosystem space. Private sector organizations, as well as, academic organizations and institutions have released number of “well thought-of”, “well designed”, and “well documented” enterprise architecture frameworks to help improve the software development processes using new and creative software engineering principles.
These different enterprise architecture frameworks varied in the way they choose to organize the different parts of the enterprise architecture framework. Each enterprise architecture framework had a different structure for the data architecture, application architecture, and infrastructure architecture. The differences included things like terms, vocabulary, artifacts, methods, processes, metrics, and tools.
Because individual frameworks described complete different sets of terms, vocabulary, artifacts, methods, processes, metrics, and tools to manage the different parts of an EAF, interoperability became an impossible undertaking. Consequently an organization that adopted a specific enterprise architecture framework could not easily change to another framework or adopt portions of other frameworks without a significant loses of domain knowledge (ASMAF will resolve this challenging undertaking by encapsulating the framework artifacts and domain knowledge within the components packaging)
Moreover, different EAFs make use of different artifacts, templates, and tools to generate knowledge artifacts. Microsoft Word is the tool of choice that is used to create most of the artifacts created by framework adopters. MS Word is a word processor, and as such, Word creates knowledge contained in text. To create true knowledge from Word documents, frameworks needed to agree on the layout of templates used by Word, which really did not happen.
Building knowledge from text is still possible through new text indexing technologies. But these methods and processes have not been mainstreamed yet. And using such new text indexing mechanisms to extract knowledge would be better used to mine the knowledge from existing artifacts and encapsulating such knowledge is reusable, re-creatable components.
Currently no single framework defines a mechanism to extract domain knowledge from the huge volume of documents that an average framework creates during an engagement. Also, tools did not materialize that allow for the extraction process to take place.
With the advancements of collaboration tools like SharePoint from Microsoft and many others in the market place, it is becoming extremely important that the knowledge that is gained through engagements by a single development organization doing business in different industries (domains) be harvested and made available through these new collaboration tools and not just be housed within the repositories of these tools.
Additionally, the majority of these enterprise architecture frameworks define different management schemas to handle:
· Change management processes,
· Project management processes,
· And development management processes.
So resources trained in one enterprise architecture framework process management methodology could not easily work within the boundaries of another.This had major negative implications for large software development organizations that had an external component to the way they do software development. Software development organizations that had an “off-shoring” component were the most vulnerable since their “off-shore” component/partner did not use the same terms and/or tools. As a result, failure in communicating the different processes led to engagements failures.
In reality, though, most of these enterprise architecture frameworks are attempting to define the same thing. And even with the large list of differences, at some stage in the enterprise architecture framework adoption process, the framework or methodology will describe an iterative development approach that the framework practitioners will have to follow with an extensive, or not so extensive, form of process management constraints imposed.
The process management piece of these EAFs is usually geared towards the distribution of responsibilities and work among the project information workers and, to some extent, the distribution o f blame (if the project fails).
Also, some of the enterprise architecture frameworks proposed some matrices and tools to help tracked the activities performed by the information workers.
In recent years, large scale adoptions of different enterprise architecture frameworks have exposed serious negatives related to these frameworks approaches to software development and to the software engineering principles defined within such frameworks.
The following list represents some of the shortcomings observed in some large EAFs adoptions:
· Inflexible designs and adoption processes.
· Involved “across-the-board” technology upgrades.
· Low levels of solutions performance.
· Unrecoverable solutions in cases of failure (DR).
· Bogged down with large volumes of documentations activities.
· Hindered by the organization political and cultural realities.
· Focused on technology cost savings versus process cost savings.
· Became dependent on traditional metrics such as source lines of code to measure and outline progress.
What is an Enterprise Architecture Framework (EAF)?
An enterprise architecture describe series of "current", "intermediate" and "target" reference architectures and applying them to align change within the enterprise. The framework part will identify what processes need to be followed and detailed information about how those processes are executed.
A typical enterprise architecture framework is composed of:
· Data Architecture.
· An Application Architecture,
· And Infrastructure Architecture.
Also an enterprise architecture framework will include methodologies to manage processes related to:
· Change management.
· Project management.
· Development management.
Sketching and Modeling
Some frameworks and methodologies will recommend the use of specific sketching tools (like Visio or RSA) and specific model notations (Like UML) to model different aspects of the system.
In recent years, some of the notations were standardized and have evolved into development languages. The process of standardizing some of the notations has helped the industry develop some common design patters and make these patters recognized by practitioners. Also some tools were developed to translate these notations into code directly (mainly UML to your favorite programming language).
Development organizations use these tools to collect requirements. At some point thereafter, some models would be created from the requirements gathered. Finally, the models that were created are introduced to the stakeholders to create consensus of what will be delivered. This usually occurs as verification of the requirements by the development team. Also, It is a way for development to explain to the different stakeholders “What the system would do” without using technical terms and jargon that some stakeholders may not understand.
In some scenarios, models generated by these tools are considered the only intellectual property (IP) the development organization own (this occur if the development of the solution is done off-shore or off-site or by a vender)
Recently, Microsoft has been pushing for a new methodology that it coined “Software Factories” principles. The key to this new paradigm of thinking has a lot to do with creating programmable models and not just sketched models.
The methodology tries to encapsulate the domain knowledge within programmable components and allow for the easiness of recreating solutions without the need to understand the underlying domain knowledge encapsulated within the model that is already created. The ideas presented by Microsoft are really ground breaking and are considered the closest the software industry ever got to the software manufacturing processes goals.
Also Microsoft did supply some tools that tried to achieve the goals of encapsulating domain knowledge and reuse.
Unfortunately, in the processes, Microsoft created tools that were more “in-line” with the old development processes paradigms than the manufacturing paradigm. The tools required extensive programming knowledge and lacked the ability to expose the knowledge it encapsulated, any true manufacturing principles, or any knowledge artifacts.
As a final point, key manufacturing principles were missing from the framework that Microsoft introduced. Things like BOM (Bill of Materials) artifacts and manifestos, Master BOM artifacts and manifestos, kitting (the process of collecting the BOMs from the Master BOM and getting it ready for assembly) processes and manifestos, TLA (Top Level Assembly) processes and artifacts, CTO (configure to order) principles, BTF (Build to forecast) principles, and RTR (Route To Rework) processes.
Never the less, component reuse was heavily addressed in the Microsoft approach and it seems that the framework has achieved that goal through the methodology and the tools offered.
Note: BOM artifacts and manifestos, Master BOM artifacts and manifestos, kitting processes and manifestos, TLA processes and artifacts, CTO principles, BTF principles, and RTR processes will be discussed in details later in this framework.
The Different Categories of Enterprise Architecture Frameworks
Modern enterprise architecture frameworks and the software engineering and methodology principles they introduced have fallen in one of two silos or categories. The first is what is known in the software engineering ecosystem space as Process Management Methodologies (PMM), the second is known as Process Improvement Methodologies (PIM). Six Sigma and Value Measuring Methodology (VMM) are perfect examples of PMM, whereas, Capability Maturity Model Integration (CMMI) and Rational Unified Process (RUP) are examples of PIM.
PMM methodologies are more business process oriented methodologies and concentrate on better performance and the overall quality of the process. Returns on investments (ROI) is another large portion of PMM(s). Most of PMM(s) have measurement methods to gauge progress, performance, and quality. But they lack clear definitions of the actual details to manage the manufacturing process itself. For example, a PMM may define the acceptable failure rate of a manufacturing activity, but does not define the process needed to actually manufacture the product itself.PMM(s) usually do not have iteration cycles and are geared towards commodity manufacturing processes.
PIM(s) on the other hand, concentrate on defining activities, documentation, and deliverables. They are more process oriented than business oriented methodologies. The ideas behind PIM(s) take into account how repeatable a process can be and how successful an organization in repeating a process with positive outcomes. Also, PIM(s) places great emphasis on the organizations ability to forecast costs and timelines using previous experiences (called the level of the organization maturity). Finally PIM(s) are iterative and do define process boundaries that play major role as milestones in the software development paradigm. As a result, PIM(s) are more adopted within the software community than PMM(s).
What is a Domain?
A domain represents an industry or a field that practitioners are trying to create an automation solution for. Examples of domains are:
· Warehouse Management
· Banking and finance
What is an ASMAF FRAK?
A FRAK (pronounced frack. The plural is pronounced fracks) is an encapsulation of a small software framework that describes “A” small reusable, easily re-creatable software component. This component can easily participate in a software product based on ASMAF framework and would be able to send and receive ASMAF messages. A FRAK represent the smallest building block in the software manufacturing process. It is a standalone ASMAF framework. Software solutions will be manufactured through the assembly of FRAKS.
A FRAK will house
1- Its own code and binaries: All the code that is needed to recreate the component is encapsulated inside the FRAK. Also, a compiled version of the component exists inside the FRAK too.
2- Documentation of all the functionalities supported by the framework: Each FRAK offer a service for the domain the component is assigned to address. Therefore, all the features that the component offers are described inside the FRAK in a features.xml document.
3- Documentation for recreation of the FRAK: The FRAK will house the needed instruction to recompile the code files housed inside it. If a make file is needed then, the make file will be included. The instructions will be included inside the create.xml file.
4- Communication interfaces: all the Interface definitions are included in the interfaces.xml.
5- All the process management unit artifacts as defined in the framework: All PMU artifacts are housed inside the FRAK. This should help anyone reviewing the FRAK the ability to trace back the engineering activities that took place when the component was being designed and constructed.
6- Tested: All FRAK code and documentations will be test.
7- Universally known as a best practice approach to the domain being served.
8- Schemas that define the data.
9- Sample Data.
10- Platform specific.
11- Domain/feature specific.
12- Can have dependencies on other FRAK(S) and must have the dependant FRAK(S) in the same development unit (DU) library.
What is Adel Software Manufacturing Architecture Framework (ASMAF)?
ASMAF is an Enterprise Architecture Framework for software development and software manufacturing. It is best described as a hybrid of a technical enterprise architecture framework, a software development framework, and an enterprise messaging bus framework that approaches Software Development (SD), software PMM, and Software PIM from a true manufacturing point of view that is tailored for software development. It combines aspects of SD, PMM, and PIM in a light and easy to follow enterprise architecture framework. It uses small building block to assemble solutions called FRAKS (pronounce fracks).
The framework defines artifacts and minimal number of tangible components (FRAKS. pronounce fracks) that the framework dictates using in a software project that the framework adaptors need to adhere to during the implementations of the framework.
Note that just like a manufacturing process has blueprints to assemble products from using prefabricated components, ASMAF has process artifacts (blueprints) and FRAKS (components) to assemble software products from.
The ASMAF framework itself is a composed of three Units (capital “U”).
First, the framework defines a 3 layered infrastructure for process management and process improvement called the Process Management Unit (PMU). PMUs artifacts must be encapsulated inside each individual FRAK.
PMU defines the “A”, “B”, “C”, “D”, “I”,”S”, “T”,”U” of the process and project management piece of the ASMAF.
“A” is the analysis phase of the EAF. This is not a technical analysis, but a sweep inventory of possible problems, possible solutions, and possible technologies. It will state the Enterprise 's aspirations and vision from an automation perspective. Analysis will be discussed in detail later in this framework. The artifacts and the artifact layouts will be supplied.
“B” represents all things Business. Things like business analysis artifacts and business use cases artifacts and models. Business will be discussed in detail later in this framework. The artifacts and the artifact layouts will be supplied.
“C” represents Cost estimates artifacts, cost distributions artifacts, final costs contacts and artifacts, and SOW. Cost will be discussed in detail later in this framework. The artifacts and the artifact layouts will be supplied.
“D” represents Deployment and Design artifacts and models. Deployment and Design will be discussed in detail later in this framework. The artifacts and the artifact layouts will be supplied.
“I” represents Implementation artifacts, models, and maps. Implementation will be discussed in detail later in this framework. The artifacts and the artifact layouts will be supplied.
“S” represents all things System and Software engineering. Things like System Glossaries, Software Architecture Document (SAD), Software Development Plan (SDP), System Vision (SV), Software requirements, Supplementary requirements. System and Software will be discussed in detail later in this framework. The artifacts and the artifact layouts will be supplied.
“T” represents all things Testing. Testing will be discussed in detail later in this framework. The artifacts and the artifact layouts will be supplied.
“U” represents User Created system abstractions. Things like Use cases, Use Case Realizations, User Interface prototypes. Users Created abstractions will be discussed in detail later in this framework. The artifacts and the artifact layouts will be supplied.
Second, the framework will houses a components library of models for the development and assembly of the software products (this piece of the framework will grow as the framework evolve) and is called the Development Unit (DU). When initially adopting this framework, organizations DU libraries will house commonly known best practices, implementations of some patters that exist in the organizations ecosystem, and some code snippets that can be salvaged and documented as FRAKS from existing solutions. As time goes by, organizations DU libraries will grow and will include FRAKS for different domains/features.
Framework users will be able to develop applications by selecting FRAKS from the organization DU library.
The DU library itself is structured as domain/feature library. It also can be subdivided based on feature/functionality. Therefore, FRAKS, by definition are domain/feature specific at the highest level. In another word, each FRAK is for a specific domain or industry and can do something specific within the boundaries of that industry.
There will be limited number of common FRAKS that are used across domains and would be housed in the common section of the DU library.
The third and final unit is a messaging framework called Common Messaging Interface (CMI) to glue FRAKS selected earlier from the development unit (DU) library together. CMI represent the glue that allows FRAKS to consume each others.
· A medical data model for patients is an example of a DU library FRAK.
· An actual analysis document is an example of PMU artifact.
· SOAP envelope load content is an example to a CMI artifact.
Also, the framework defines the processes that these tangible artifacts/Components/FRAKS create and define their content.
One consequence of defining tangible artifacts/Components/FRAKS is the restrictions and limitations that these tangible artifacts/Components/FRAKS impose on a software solution being developed. A data model component (FRAK) from ASMAF DU library, for example, may impose restrictions that may limit its use in a specific automation solution or specific domain. To work around these implied limitations and restrictions, the framework will allow
1- For the evolution of the each tangible artifact/component/FRAK.
2- The framework will support extensibility through the use of a new concept called Software Manufacturing Unit (MU). The MU (pronounced em- you) development principles are supported by the majority of new modern languages. MUs (pronounces em-yous) only apply to the DU portion of the framework and they will be responsible for manufacturing the pieces of functionality that the ASMAF FRAK do not support natively or out-of-the-box. In reality, MUs principles build on “late binding” paradigms exposed in new none declarative languages and some declarative ones.
The FRAK and MU principles will be defined in depth later in this framework.
Finally, like all the other enterprise architecture frameworks, ASMAF have an iterative piece. But ASMAF will embrace iterative development principles from a fundamentally different point of view compared to existing enterprise architecture frameworks. Using ASMAF, the majority of activities that adopters and practitioners will perform will fall in the realm for software components manufacturing and packaging and not fully fledged software development. The ASMAF manufacturing process will be an iterative process of its own, but it will be part of the software manufacturing quality control steps and not part of the software manufacturing process steps. Iterative approaches in ASMAF are really refactoring iterations and not true software development iterations.
So what makes this new enterprise architecture framework different than any other enterprise architecture framework that exists in the ecosystem today?
Well, as you will see, Adel Software Manufacturing Architecture Framework (ASMAF) is an evolving framework that does not just define approaches and processes tailored to software development, software management, and software engineering, but actually define the overall software development process as a manufacturing process for the sole purpose of creating “A” software products. It uses the true manufacturing principles in helping practitioners manufacture software from prefabricated components.
Using ASMAF, applications will be created using predefined FRAKS. These FRAKS would be glued together through a messaging framework. The messaging framework allows the FRAKS to communicate and consume each other. Finally, the framework define a 3 layered process and project management framework called the project management unit (PMU) and list all the documentation that will be generated.
Software in Perspective
Software products and solutions, counter to popular belief, are 90% the same. The only advantage an organization gets from implementing one automation solution from any other occurs when the 10% deviations between automation solutions fits the organization line of business, culture, and is widely accepted by the organization users. As a result, this framework will try to, with time, building standard manufacturing pieces for the 90% of all software products for one platform using a single technology and leave the 10% deviations to each individual domain/industry practitioners. Also, other organizations are encouraged to build the framework for other platforms and technologies.
The framework itself will define models and house some FRAKS.Organizations that adopt this framework may start their own DU library and not use any from the framework. They only need to follow the framework guidelines when creating FRAKS to be housed in their DU library.
Also domains subject matter experts are encouraged to contribute to the framework as the framework evolves.
The vision behind this framework is that one can actually manufacture 90% of solution requirements without the need to spend long hours and/or create a huge effort recreating things that were created before and were proven to work on the platform and technology being targeted.
Also, the knowledge encapsulated in existing solutions and component binaries will allow for better reuse of domain specific needs and requirements.
The major principle or vision can be summed as follows:
“One can manufacture the majority of an enterprise software solution from existing components or prefabricated components and only engage in development processes for tailor pieces of that are line of business specific.”
It is worth mentioning here that the concepts used in this framework are not new to the software engineering practitioners and the industry have tried and failed the last 30 years to do this in some shape or form. It seems that the industry settled for the nascent concepts of best practices and patterns white papers to address reuse and software manufacturing. Also, the industry has showed some limited success in the hiding of domain knowledge through the use of sketched models.
True software manufacturing has not materialized and this framework and the concepts described within it are geared to put an end to this unfortunate reality. The concepts here will not propose new software tools, new languages, or new sketching paradigm. As you will see, it is a compilation of software engineering concepts, organizations processes concepts, the use of best practices principles, and a new software engineering concept of architecture component packaging (ACP) that will allow for the processes of software manufacturing and remanufacturing to actually take place.
Software as a Commodity
With recent changes in the Information Technology (IT) marketplace, mandated by the new globalization of the world economies and advancements in communication, major shifts in how business viewed software development took place.
Software is no longer viewed as an advance activity organizations get involved in to automate daily business operations. Software is now viewed as a commodity that is bought and sold. And as such, software development should then be managed like any other commodity. Historical “tried and proven” manufacturing management processes can now be impose on software development. Or, at least, that is the general thinking.
While this shift in the software development paradigm was taking place on the business side, true software manufacturing methodologies and processes did not really exist. They actually still do not exit to this day. In general, software engineering and software process management, as a field of study, was and still to date an infant field of study. As a result, software development organizations started adopting other process management methodologies (specially manufacturing methodologies), like Six Sigma, and tried to force fit software development/manufacturing into these methodologies and paradigms.
On the process improvement side of the software development equation, large number of academics took the scholastic approach to improving the software development processes. The idea was to document every aspect of the software development process and all the activities associated with it. Then create tools and artifacts to help manage all these documents and activities and hope for the best. These types of frameworks claim to help predict cost and timelines associated with specific solution too. These attempts were branded the word “Maturity” frameworks and a number of such frameworks exist in the market place. The most widely known is the CMMI framework. These frameworks are the most comprehensive and have an actual real chance of succeeding if implemented correctly. The only limitation to the “Maturity” frameworks had to do with their heavy documentation aspects that made practitioners veer from the original frameworks through tailoring. Once tailored, these frameworks have a tendency to lose a lot of their engineering effectiveness and as a result, drive failed projects and solutions. In this scenario, framework actually would have worked, but the practitioners are usually the reasons behind it not working.
Finally none of the existing framework dictates using all aspects of the framework as defined by the framework designers. The majority of frameworks make most or even all the pieces of their frameworks optional so organizations can tailor the framework to fit the organization project needs. This increases adoption of the framework but reduces the actual value of the framework.
In general, these tailored approaches end-up being large documentation activities with little to no reuse. Also, no manufacturing principles will ever be used because of the looseness of the process. And if you ask any development manager that implemented such tailoring to one of the existing frameworks and you will quickly get the impression that they are inside Microsoft Project most of the day managing activities and documents.
The end results of this era of thinking is frameworks that are either heavy handed on documentation, heavy handed on modeling, or heavy on facts gathering, but never actually heavy on reuse and building reusable components.
Promises of CASE and MDA
Computer-Aided Software Engineering (CASE) and Model Driven Architecture (MDA) are two architecture approaches that tried and are still trying to create a paradigm that is the closest to a true software manufacturing principles. The general idea behind the concepts here is that software is really developed through the use of modeling tools. And since Business folks can understand models, they are in a better position to create the solution using business models they created. The only problem with these architecture frameworks is the tools. Tools have not been able to keep pace with the needs of the modelers. In most cases synchronizing the model was at best a bad experience, at worse, broke the application.
Then came SOA
SOA can be everything to all the practitioners or something for some practitioners. But, at a minimum, SOA cannot be ignored when evaluating enterprise architectures. The truth behind SOA is the fact that it was the inevitable solution to the industry failures in creating a true manufacturing model for software development. At some point, business folk started looking at solutions as individual features housed into individual application (silos). They started asking the practitioners if they can use some features from one application into other one. Since the practitioners did not have an easy way of recreating/remanufacture the features in-question, the next logical thing was to expose the feature to the consumer from within the housing application (silo).
SOA, in general, is not a new concept and is based on the fundamental principle of object oriented development were one object consume other object features/services/methods. During the early days of object oriented programming, we lacked the platforms that could do this outside the boundaries of a single application
In recent years, with the advents of native OS frameworks like ASP.NET and ECLIPS and native OS application servers like IIS and WebSphere it became possible to expose these features/services/methods outside the application boundaries and to the rest of the outside world. New technologies like SOAP, and the wide acceptance of the XML standards helped immensely is speeding the adoption process.
SOA principles do not align with software manufacturing principles though. SOA encourage features reuse and not software components reuse. As a result, this framework will actually consider SOA components a byproduct of the software manufacturing process. In short, one can use this framework to create SOA components/FRAKS.
For additional Information on SOA, please see the following links
Burton Group SOA RA
IBM SOA RA
BEA (+ some consortia) SOA RA
Why Software manufacturing and not software development?
To answer this question, one should take a closer look at any components manufacturing activity that is taking place in any plant or factory in the world today. The use of prefabricated components has been the cornerstone of all the gains the manufacturing industry has been able to achieve in the last 100 years or so. Sometimes it is called specialized component manufacturing. Some other times it is called assembly line manufacturing. But over all, it is the process of using previously manufactured components to create new products. These components are assembled together to create the final product.
This manufacturing process has proven successful in the manufacturing large volumes as well as small to medium specialty manufacturing (low quantities manufacturing).
A great example of an industry that championed and embraced the manufacturing by components is the PC industry. The PC industry is a great example of a manufacturing industry that was able to create a multitude of companies, plants, and products based on the pure use of the principles of component manufacturing. In fact, the only reason personal computers have been growing (skyrocketing)in power and sophistication but maintaining low cost is because the PC industry have standardized on the use of computer hardware components as the building blocks of each PC a long time ago.
Also, the software crises the industry faced the last century and is still facing today forced a shift in the thinking toward commoditization of the software development processes. Software engineering process improvements (PIM) are playing a major role in this shift of thinking. PIMs are proposing processes in which projects are divided into smaller pieces to be developed/manufactured anywhere in the world. The concepts are easy to understand by the business and by management and have great promises of solving the software crises that have plugged this industry for half a century now. The immediate and noticeable results are the huge adoptions of PIM(s) by all kinds of software development shops.
Commoditization of software meant that companies can get what they need when they needed it. Or at least that is the thinking
Also, a “tie-in” to a single platform, technology, or language by any single development organization has evaporated as a result of powerful market forces. A development organization will engage in 6 to 8 automation solution a year with multiple platforms, multiple partners, and multiple vendors using different platforms, programming languages, communication stacks, and tools. Large software organizations, especially, engage in hundreds of solutions a year with all types of teams and expertise. This diversity in technologies and personnel has lead to “domain knowledge sprawl”.
During automation engagements, domain knowledge get encapsulated into solution binaries and practitioners brains, and some knowledge make it into documentation. But as solutions get larger in size, more and more functionality and features get siloed into these solutions. Unfortunately, once the solution is delivered, most, if not, all the domain knowledge disappears. In fact, with the emerging of off shoring software development, the domain knowledge all by evaporated.
Cost and quality are also benefits that can easily be quantified in a manufacturing environment but usually are hard to do in a development environment.
In reality, cost-benefits and the increase in reliability will fuel the rise of the software manufacturing principles and away from the standard software development principles that have been used in the last 40 years.
Next>>Please Contact the Author
© 2011 Advance database research and Development corp. All rights reserved.