Adding Simplicity - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Information Management

Adding Simplicity

Automated, model-driven architecture could be your ticket to simpler, less painful enterprise development.

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
1 of 2
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

11 Things IT Professionals Wish They Knew Earlier in Their Careers
Lisa Morgan, Freelance Writer,  4/6/2021
Time to Shift Your Job Search Out of Neutral
Jessica Davis, Senior Editor, Enterprise Apps,  3/31/2021
Does Identity Hinder Hybrid-Cloud and Multi-Cloud Adoption?
Joao-Pierre S. Ruth, Senior Writer,  4/1/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Successful Strategies for Digital Transformation
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll