Adding SimplicityAdding Simplicity

Who has time to worry about the intricacies of every technology deployed in the enterprise? I just want to write out my requirements, possibly in some formal way, and have an enterprise architect be able to quickly translate those requirements into an application ready for deployment. I want this done regardless of the platforms or languages used, and I want it done in months, not years. Yet it still takes years to develop decent enterprise applications.

Technical salespeople have been selling me their new miracle products for years, and while each one has helped in small ways, it still takes me longer than it should to get what I need to get done. I still have to muck around with platform- and language-specific details to get any of it working. Not to mention the myriad of scripting tools I use just to glue it all together! Each new technology is presented as the next saviour of the ROI movement. And yet, doesn't it seem that every one of these new technologies just adds more complexity to an already complex enterprise? Automated model-driven architecture (aMDA) just may hold the answer to this common CTO quandary.

Origin of Complexity

Remember the good old days of Visual Basic and PowerBuilder? That was back in the days of client/server systems when all you needed was a glorified GUI to access some server-based database. Two-tier architectures were the norm, and only occasionally did you need to venture out into the three-tier world. Then the Internet took over, and distributed applications became the must-have. Things started getting very complex after that.

And now to add to this nightmare, service-oriented architectures are replacing our comfortable synchronous world with message queues, loose coupling, and asynchronous communications. J2EE is now the language du jour for elite software developers, and their rallying cry has always been portability and open standards.

But J2EE has only added to the complexity with myriad frameworks for Web presentations (servlets, JSPs, Struts, JavaServer Faces, Turbine, Page Flows, and portal frameworks) and persistence layers (CMPs, JDO, POJOs, and Hibernate). Not to mention the huge amount of specifications and APIs that make up J2EE and the art of deploying to multiple application servers whether you're using JBoss, Weblogic, WebSphere, or Oracle. Did they make it this complicated just to force you to pay J2EE consultants a lot of money to help translate your requirements into their codified Greek?

Unfortunately, we're not going to get rid of the complexity. Some may argue that Microsoft .Net is simpler because it mimics the framework behind J2EE yet is a lot easier to develop and deploy because you're only dealing with a single toolset. But you still have to worry about proprietary standards and platform battles, and there's a very large learning curve to go from Visual Basic 6.0 to Visual Basic .Net. You still need .Net gurus to figure it all out.

The next argument is that Web services should even out the playing field because it's the paradigm for heterogeneous integration. However, go read the hundred or so Web service standards that exist or will exist and then get back to me on how simple Web services really are. Even if only five or six of those standards are actually necessary, you still must deal with the myriad of frameworks and tools that bind these XML documents to a particular language or platform. Again, there's no getting away from the simple fact that this is all not so simple.

Looking for Answers

So what to do? If you can't get away from the complexities inherent in the technologies used to implement these enterprise applications, how do you accomplish what you need to get done in the ever decreasing amount of time you have? The answer isn't in better tooling or newer technologies, although both are very important in implementing solutions. The answer isn't componentized frameworks, although you shouldn't build an enterprise application without them. The answer isn't even methodology, although you're getting close. The answer is aMDA. Although you may have heard of MDA, the addition of the adjective 'automated' isn't seen as often. It's an important addition to the initial concept, but for those not familiar with MDA, let me tackle that first.

Model-driven architecture has been around ever since modeling became a popular way of documenting and designing applications. However, the term and the concept itself received some formalization by the Object Management Group (OMG) sometime after 1997. (The OMG is a nonprofit software industry consortium whose charter includes providing a common framework for application development.)

As OMG puts it, "MDA development focuses first on the functionality and behavior of a distributed application or system, undistorted by idiosyncrasies of the technology or technologies in which it will be implemented. MDA divorces implementation details from business functions. Thus, it's not necessary to repeat the process of modeling an application or system's functionality and behavior each time a new technology (for example, XML or SOAP) comes along. Other architectures are generally tied to a particular technology. With MDA, functionality and behavior are modeled once and only once."

Most MDA implementations are tied closely to unified modeling language (UML) as a means of describing the architecture. Initially, you develop a computation independent model (CIM), which is essentially a business model of the system. It's an abstraction of the system that shows it in the environment in which it will operate while hiding the details of the system's structure and leaving the processing details undetermined. Following this model is the platform-independent model (PIM), which describes the system in a lot more detail without being specific about platform or language. Finally, there's the platform-specific model (PSM), which is used to tie the description of the system in the PIM directly to the platform and language being used. This model can then usually be transformed directly into code and other supporting implementation artifacts.

For instance, at the CIM level, you may simply have an analysis component that's marked as a boundary object. At the PIM level, that boundary object is then transformed into a series of components labeled as persistence objects. Finally, at the PSM level (if you're using J2EE), the persistence objects are then transformed into EJB entity beans. With each transformation, the architect is free to mark objects as needed and change the structure of things, but the idea is that the changes are reflected both up and down the model chain and finally into executable code. At the highest level, the architecture comprises nothing but requirements, activity workflows, and high-level ideas of components and subsystems. This highest level hides all the complexities of architecture and the technologies that implement it. Thus, it lets users at a business level communicate with an architect directly about what they need and lets architects easily put these requirements into a framework in which they can then transform these high-level needs into concrete enterprise applications.

Automation is the Answer

This ability would all be for naught if there weren't tooling available to ease the work behind MDA. And that's where the term 'automated' MDA becomes so important both to facilitate the work of employing MDA as well as reducing the amount of manually introduced errors into the process. Many third-party vendors are now creating tools and transformations that do some or all of the PIM to PSM conversions for you. In addition, many of these tools keep a traceability log between the high-level ideas and the final executable components. Tie this methodology to an iterative development life cycle, and you have enterprise applications that are easy to define and deploy and will meet stakeholders' needs.

Although MDA isn't a new concept, it's only begun to become an important strategy for developing powerful enterprise applications. The introduction of automation to this methodology is the key to making it successful. On the one hand, you can keep the complexities inherent in your software; on the other, you can define your requirements and architecture without taking those complexities into account.

Automation offers mechanized transformations between the less complex, high-level models and low-level code. Although tweaking and business logic still needs to be completed at the code level, a lot of the work has already been done for you. In the end, it leaves you with a highly reusable enterprise application developed quickly while meeting the immediate needs of the business. Automation doesn't necessarily make enterprise development easier, but it sure makes it a little less painful.

Michael J. Hudson [[email protected]] is a software architect for Praxis Engineering Technologies in Annapolis Junction, Md. His current work includes developing enterprise architectural solutions for both commercial and government clients.