|
| MODEL DRIVEN ARCHITECTURE [MDA] |
The Business Case
The Need for Business Agility
To thrive - or even to survive - in today's competitive marketplace, companies need to continuously balance differentiation (for top-line growth) and productivity (for bottom-line profitability).
How quickly you can react to internal and external changes, usually spells the difference between mere survival and MARKET LEADERSHIP.
To succeed, you need a flexible IT architecture that enables you to quickly implement new, innovative business processes, without changing core business engines.
Lack of Business Agility Everywhere
How agile are you?
|
| |
 |
By the time the business analyst understands what you need and writes the functional specs and gets them approved by you and writes the technical specs and give that to the architects to design the change and the programmers get the program specs and they write the code…. YOU GET THE IDEA.
By the time traditional I.T. delivers, the business rules have changed, and you begin the change implementation cycle once again. As a result, I.T. is always 4-6 months behind where the business needs it to be, and it is not a question of better hardware, better people, better training or more money. The solution is not India.
You might ask: What about Agile Methodologies, such as Scrum and XP?
They do compress the “go live” time for certain kind of changes, but you are still firmly dependent on IT to deliver.
What about SAP, Oracle Apps and other Enterprise Applications?
What Classic SAP (R/3 or mySAP ERP) and other enterprise applications do really well is automate core and non-core processes that are essential for running a business but not necessarily for differentiating it. These are called “Best Practices” and comprise all the things that companies need to do in order to be a functioning business entity, such as inventory management, invoicing, order-to-cash, and so on. When it comes to differentiating processes, one needs to build something that reflects this uniqueness. With SAP, this means custom development using ABAP and related coding facilities – consuming time that you may not have and money that you can ill afford. As a result, business agility becomes a primary concern. The question arises: Even after you have mapped your differentiating processes on to SAP, how quickly can you adapt to changing business conditions and adopt newer ways of conducting your business when the need arises? The answer is: Not very quickly.
What is the main problem?
The key problems appear to be as follows:
- The business people are the source of all the requirements but they are powerless to implement any of them and must depend on IT folks to do so.
- The business people and the IT people do not talk the same language and this gap needs to be filled in by Business Analysts, adding yet another layer to the communication process and the potential for miscommunication.
- Software development and maintenance is still a labor-intensive process.
Towards a Solution Strategy
What if...
What if we could isolate the Business People from the IT People so that they didn’t ever have to speak to each other?
What if we could give let the Business People specify their requirements in pure business language and with diagrams (what IT People derogatively call “pretty pictures”)?
What if, after the Business People had finished specifying the requirements, the specs and the “pretty pictures” could be automatically converted into programs that the IT People could then deploy and run?
This would also give the Business People the opportunity to makes changes in their requirements and “pretty pictures” whenever circumstances changed, and then automatically regenerate the modified programs for instant deployment. True IT agility that would lead to great business agility!
Implementing the Strategy
Nice dream?
No. Reality!
Model Driven Architecture (MDA) makes it possible. Today! |
|
| Model Driven Architecture [ MDA ] |
MDA provides an open, vendor-neutral approach to the challenge of business and technology change. Based on OMG's established standards, MDA separates business and application logic from underlying platform technology. Platform-independent models of an application or integrated system's business functionality and behavior, built using UML and other associated OMG modeling standards, can be realized through MDA on virtually any platform, open or proprietary, including web services, J2EE, .NET, and others. These platform-independent models document the business functionality and behavior of an application separate from the technology-specific code that implements it, insulating the code of the application from technology and its relentless churn cycle, while enabling interoperability both within and across platform boundaries. No longer tied to each other, the business and technical aspects of an application or integrated system can each evolve at its own pace -- business logic responding to business need, and technology taking advantage of new developments -- as the business requires.
|
 |
| Explaining Model Driven Architecture (MDA)
What is a Model ?
A Model is a representation of something – anything. Such as: |
|
How does Modeling help?
Now that we know what a Model is, let us examine three other terms: System, Modeling and Simulation.
What is a System ?
A system is a set of procedures and resources that accomplish a well-defined function. (Expanded form: An organized assembly of methods, resources and procedures which are united and regulated by interaction or interdependence to accomplish a set of specific functions.)
A system can be a concept (such as: the “Six Thinking Hats” by Edward de Bono) or an object (such as: the Solar System). Other examples from real life: a production system in a Steel Melting Shop (a complex system of infrastructure, equipment, man and material that produces liquid steel); a bus (a mechanized mobility system that provides transportation); a house (an infrastructure and services system that provides habitable space); a human resource system in a corporation (a set of procedures, people and software that manages human capital).
What is Modeling?
Modeling is the act of creating a “model” (which is a representation of something) of a system.
The act of building a model can be complex because we have to build into it all the characteristics of the real thing. Depending on the complexity of the system (which can also be an object) that we are trying to model, this could be hugely intricate requiring great expertise.
What is the purpose of modeling? To promote understanding of the real system = to “better understand” the real system. Whether a model is a good model or not depends on the extent to which it promotes understanding.
What is Simulation?
Simulation is the act of manipulating a model to study how it behaves in different situations. It is akin to “what if” analysis.
Simulation often operates in such a way that it compresses time and/or space – that means, works in a smaller space and in a shorter time. Think of a model airplane going through the Wind Tunnel simulation. In a much smaller space (than the sky) the simulation puts the model through a wide range of situations that a real plane might actually experience over several years or even never. This time and space compression enables us to study the behavior of models in a easily manageable manner and at reasonable cost.
So if the declared purpose of modeling – as stated earlier – is to promote understanding of the real system (the real thing), then it is simulation that ultimately delivers that knowledge, insight and understanding into the behavior of models – into the interaction of the parts of a system, and of the system as a whole.
In order for simulation to deliver this benefit, the model must have all required characteristics of the original system built into it. If too little detail is included in the model one runs the risk of missing relevant interactions and the resultant model does not promote understanding.
If too much detail is included in the model the model may become overly complicated and actually preclude the development of understanding.
The following is the typical Model-Simulate Cycle that establishes a complete understanding of the system, leading to a successful build: |
|
Many people use the words “modeling” and “simulation” interchangeably, so much so, that it is not uncommon to use the word “modeling” to mean “model creation and simulation”.
The MDA Process
The goal of MDA is to create and maintain software that operates a system.
The goal of Traditional IT (and All IT everywhere) is exactly the same.
It is how MDA achieves that goal is where it differentiates itself from Traditional IT and represents a paradigm shift in software engineering. |
Basic Philosophy
The basic philosophy behind MDA can be summarized as follows, before we go into the details:
- Isolating business people from IT people so that they don’t have to talk to each other.
- Empowering business people to independently define specifications of the system in the form of a business model.
- Using IT people to independently add technology to the business model and use automated model-to-model transformation procedures to generate the source code.
PIM: Platform Independent Model
MDA isolates the business people from the IT people and forces them to think of their business goals in a pure business environment that is devoid of technology; to think only about the business in a technology-agnostic manner; not to think about the technology that will implement the business system. This is what we call Platform Independent Modeling (PIM) in MDA parlance.
PIM is a business model that is completely dissociated from technical considerations and is not concerned with technical implementation or physical deployment of the model on a specific hardware/software platform. PIM, therefore, encourages and enables process-centric thinking and pure business focused solution determination. It also enables business people to take complete ownership of “their business processes” instead of having to depend on the IT department to translate all their concepts into a tangible form.
The PIM is created using Unified Modeling Language (UML) and other resources hosted on a BPM (Business Process Management) tool.
PIM, by insisting on a business-only approach, encourages process-centric thinking as opposed to the "data centric" thinking of traditional IT, and results in the creation of process-centric systems.
PSM: Platform Specific Model
Before a Platform Independent Model (PIM) can be utilized to automate or perform a business objective, it must be implemented in an executable format, and that requires a target hardware/software platform.
So once the Platform Independent Model (PIM) is final, technology is then applied to the PIM and the relevant model-to-model transformation procedures automatically transform the PIM into a Platform Specific Model (PSM).
PSM = PIM + Technology = Technology-aware version of the PIM
The Platform Specific Model (PSM) specifies the system in terms of the implementation constructs that are available in the implementation technology of choice.
Let us say you wish to deploy an application on a J2EE platform using Hibernate annotations, Spring MVC and Java Server Faces (JSF) user interface on a Sun Microsystems Unix computer. OMG, under its MDA initiative, specifies the use of code generators that will read the machine readable Platform Independent Model and produce executable code – but the transformation occurs in stages. More information on how this transformation takes place follows
The PIM to PSM transformation is the first transformation and is an intermediate stage before code generation can occur.
Source Code (another kind of PSM)
Finally, with the PSMs in place, source code can be automatically generated. Source Code is also a different kind of Platform Specific Model (PSM) and is the result of the second automated transformation.
Over the recent years, automated code generation has become particularly strong as a viable technology, and lots of vendors are supporting the MDA framework. |
A Schematic Look at MDA
Let us consider the schematic below that depicts the framework with a little more explanation. |
|
In reality, multiple Platform Specific Models (PSMs) are likely to be generated, as shows in the following diagram: |
|
In this example, one PIM gives rise to two PSMs because the implementation technology involves Java and Oracle RDBMS. During the first transformation, the PSM Bridge is also automatically generated by the MDA tools, and when the second transformation occurs, the corresponding Code Bridge – which is XML as the transport protocol connecting the Java and the Oracle – is also automatically generated.
What is Model-to-Model [M2M] Transformation ?
Transformations are essential in the MDA development process, because a business model – the PIM – is ultimately useful only when the business processes are actually implemented in executable form. Automated model-to-model transformation leading from the PIM to executable code is the unique value MDA adds to the software engineering discipline.
As we have seen, a transformation tool takes a PIM and transforms it into a PSM; a second transformation tool transforms the PSM to code. So far we have shown the transformation tool as a black box. It takes one model as input and produces a second model as its output.
When we open up the transformation tool and take a look inside, we see that somewhere inside the tool there is a definition that describes how a model should be transformed. We call this definition the transformation definition, and it consists of a set of transformation rules.
Definitions
A TRANSFORMATION is the automatic generation of a target model from a source model, according to a transformation definition.
A TRANSFORMATION DEFINITION is a set of transformation rules that together describe how a model in the source language can be transformed into a model in the target language.
A TRANSFORMATION RULE is a description of how one or more constructs in the source language can be transformed into one or more constructs in the target language.These transformation rules are unambiguous specifications of the way one model can be used to create another model. The transformation specification relates constructs from the source language to constructs in the target language. We can, for example, define a transformation definition from UML to C#, which describes what C# code should be generated for a UML model.
Basic Requirement
One of the very basic requirements of Model-to-Model Transformation is that a transformation should preserve meaning between the source and the target model.
QVT = Query View Transform
Object Management Group (OMG) has created the specs for QVT that is recommended within MDA as the prime transformation language.
Benefits of MDA
1. Virtually instant implementation of changes. Business people will modify the Business Model and IT people will automatically re-generate and deploy the changed software. Unbelievable but true.
2. Very low software maintenance cost. You do not any longer maintain source code. Business departments will maintain their respective Business Models and a small IT department will maintain the model-to-model transformation procedures (PIM-to-PSM mappings) to automatically re-generate software whenever business departments make changes to the Business Model that they want to deploy. Huge cost savings.3)
3. Better process orientation and true process-centric systems because all the focus is now on Business Models and not on software development.
4. Institutionalization of knowledge. No longer will the company lose a body of knowledge and expert every time significant employee leaves. All operational knowledge and much decision-making knowledge will remain secured in the Business Model.
5. Competitive advantage through business agility. Now, at long last, when business people take a decision, they know that the decision will be instantly reflected in the company's information systems. No longer will business agility be thwarted by the Business-IT divide. Much competitive advantage can result from this.
6. "Future proof" Solution. Even when technology changes, the Business Model will never be scrapped. IT department will revise the model-to-model transformation mappings (PIM-to-PSM mappings) to deploy the then-existing Business Model using new technology.
Many other advantages, too numerous to elaborate here.
How does MDA give us Business Agility?
Maintainable Business Models instead of Maintainable Source Code
Whereas Traditional IT give you maintainable Source Code (which must be maintained by techies), MDA give you maintainable Business Models (which can be maintained by Business people).
When a change occurs, Business people need not talk to IT people at all. They will simply incorporate the relevant changes in the Business Model and tell IT to fire the model-to-model transformation procedures to generate the revised Source Code and deploy that.
That is how MDA gives you great IT agility which can result in great Business Agility. Finally, changes in the system can be implemented by business people without depending on IT.
|
The MDA Change Management Process
The following schematic illustrates the change management process under MDA: |
 |
Notice how Business Units do the main work, while IT just fires the MDA process of automated model-to-model transformations that ultimately results in the change being deployed.
Summary
To summarize, we can only reiterate how we introduced MDA
MDA provides an open, vendor-neutral approach to the challenge of business and technology change. Based on OMG's established standards, MDA separates business and application logic from underlying platform technology. Platform-independent models of an application or integrated system's business functionality and behavior, built using UML and other associated OMG modeling standards, can be realized through MDA on virtually any platform, open or proprietary, including web services, J2EE, .NET, and others. These platform-independent models document the business functionality and behavior of an application separate from the technology-specific code that implements it, insulating the code of the application from technology and its relentless churn cycle, while enabling interoperability both within and across platform boundaries. No longer tied to each other, the business and technical aspects of an application or integrated system can each evolve at its own pace -- business logic responding to business need, and technology taking advantage of new developments -- as the business requires.
How MDA Assists with Software Modernization
Since most companies already have a massive volume of traditional software, it is imperative that MDA should provide a roadmap how that all that software could be migrated into the MDA environment so that a company may adopt MDA as their software engineering methodology.
This roadmap is the Software Modernization Roadmap provided by MDA that we follow. It is called Architecture Driven Modernization |
|
|
