The enterprise application as we know it is dead. Zombie-like, it still lumbers along, lifelike enough to fool many IT professionals. But, make no mistake - it is dead.
In today's climate of ever-accelerating change, big, one-size-fits-all applications do not help organizations do business more effectively. The monolithic applications that prevent companies from adapting to new business challenges are giving way to a matrix of services called the service-oriented architecture (SOA).
The complexity and rigidity of traditional systems results in the too-familiar misalignment between IT and the business. The IT side is bogged down with the burden of maintaining 20th-century systems and processes that have become too bloated and inefficient to deal with the demands imposed by the 21st-century business environment. In many organizations, that maintenance burden approaches 80 percent of the total IT budget.
This is not news to IT professionals, who for years have put up with these headaches, because they had no alternative to automate critical business processes. Inflexible automation was better than no automation at all - until now. Enterprises can adopt an SOA and create applications composed of modular software components that are interconnected through well-defined, open Web service standards.
Just as companies moved from mainframe to client-server, so must IT move from monolithic applications to a matrix of loosely coupled Web services that enable the composition and recomposition of business processes.
For example, checking an account balance is a common function in banking applications. In a traditional architecture, each new banking application would include code to check balances. In an SOA, "check account balance" would live as a Web service. Any application requiring that functionality can simply link to the appropriate Web service.
The biggest benefit of SOA is flexibility. An SOA allows the enterprise to quickly change its infrastructure in response to changes in the business environment, because most of the basic processes are already available as Web services. New functionality can be developed as a Web service and linked back to other necessary business processes. The business can adapt and thrive.
While the value and inevitability of building SOAs are generally recognized, many organizations have failed to revamp their approach to building software. Almost everyone understands the importance of a service architecture's ability to deliver cost savings and agility. But we are in the frothy part of the adoption curve, where everyone is adopting SOA - even those who aren't entirely sure how to do it.
A recent high-level SOA and Web services conferencefeatured an SOA panel that consisted of four engineers and a marketing professional.
After the engineers finished their detailed spiels on Web services, the marketing person said, "I'm not sure I understood any of that, but," at which point the audience burst into applause.
But don't be fooled: SOA is not just another overhyped IT trend. Organizations that have deployed well-managed SOAs are seeing enormous gains in cost-savings and infrastructure flexibility. Unfortunately, too many IT departments are building Web services as though they were constructing the cumbersome, stand-alone applications whose demise they are to oversee.
These organizations must destroy development silos. Web services are inherently interdependent and connect with middleware components, legacy systems, e-business applications and other software assets in the IT environment. Unless development teams communicate and collaborate effectively, an SOA will end up increasing complexity and costs.
Companies also must ensure that the development of Web services adheres to a target architecture. The failure to focus on architecture results in an architecture that is largely crippled, rather than loosely coupled. Architecture often lives in inert PowerPoint or Word documents that are rarely read. IT management and development project leads must establish governance practices and systems that require project teams to follow the architecture, adhere to standards and ensure that services are in compliance with the SOA.
Finally, it is critical to deploy a central registry/repository that discovers, identifies and maps services for reuse, and that understands the relationships between various services. If no repository is in place, Web services and other applications built on the SOA will be developed in isolation and misaligned with architecture.
The application as we knew it is dead, and yesterday's monolithic IT infrastructure is being deconstructed into a dynamic matrix of loosely coupled services. The transition to SOA will not be easy; we must learn to build and manage this new software in new ways. But the result will be the agile, on-demand enterprise.
Stack is the CEO of Flashline, a provider of SOA and software asset portfolio management solutions. He can be reached at email@example.com.