Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
While the motivations for bothering with Enterprise Services Architecture at all lay primarily in the realm of business, the reasons that Enterprise Services Architecture has become a short-term imperativelie in the realm of technology.
The design principles of Enterprise Services Architecture spring from mature concepts and techniques such as service-oriented architecture, modeling, and object-oriented programming. Up to this point, these ideas have mostly been relevant to advanced system architects who employed them in creating elegant implementations within applications.
But the expansion of automation throughout the enterprise,the arrival of technologies such as the Internet, XML, Web services, and business process management standards, and the maturation of a full set of platform systems for content management, data warehousing,and portals all create the necessary conditions for important architectural ideas to break out of the realm of theory and to start informing the creation of business technology.
Enterprise Services Architecture provides the opportunity to reorganize three generations of business technology around proven architectural principles from computer science. The mainframe era, the client/server era, and the Internet era all filled out the toolbox, creating standards, enterprise applications, and platform component systems to meet the fundamental application and functional needs ofthe business world. Enterprise Services Architecture now seeks to make sense of it and apply some structure to increase the value businesses can extract from technology.
The reason that Enterprise Services Architecture has gone from a good idea that might happen someday to an exciting opportunity right now is that a variety of elements that have evolved over time are now able to interact in a new way. This is similar to biological evolution in which parts of an organism gradually morph until they all work together differently and enable a major leap forward. Enabling factors in Enterprise Services Architectures evolutionary process include the availability of advanced development tools, networking standards, and standardized data structures.
The first factor setting the stage for an evolutionary leap is the full suite of enterprise applications developed over the past 30 years. The core financial and control functions were the initial focus of themainframe era. Applications grew out from this core gradually. During the client/server era, their footprint expanded as applications for Human Resources and Sales Force Automation took root. In the Internet era, the pervasive network allowed applications like Customer Relationship Management, Supply Chain Management and Supplier Relationship Management to automate processes. As a result of these phases, most corporations have collected a heterogeneous mix of applications from many different vendors.
The second major factor in the evolution of infrastructure is the parallel development of platforms and toolkits for a broad scope of application functionality. At the foundation are the operating systems themselves, which provided the base on which computer languages, interactive development environments, and related developer tools were constructed. Relational database systems gradually matured into a stable repository for persistent data from most applications. Platform component systems for content management,data warehousing, and application integration all provided powerful toolkits to build custom applications and extend the functionality of existing legacy and enterprise applications.
A third development that makes Enterprise Services Architecture ready for prime time is the way the Internet broke through the armor that surrounded the enterprise. With TCP/IP as the standard way ofcommunicating across networks, web browsers based on HTML as the user interface, and HTTP as the communication protocol, enterprise applications could now reach out directly to consumers and suppliers. Applications could also more easily communicate with each other. The investment boom that grew from these technological developments resulted in the acceleration of the growth in enterprise applications and platform component systems. Network-oriented enterprise applications and platform components such as application servers and enterprise application integration (EAI) systems were created in this period.
Data is being prepared for Enterprise Services Architecture through XML. Inspired by the simplicity and popularity of HTML, the ornate and complicated language of SGML was distilled into XML, a flexible way to describe the structure of data. XML also describes interfaces and protocols in a way that is interoperable across different applications and platforms. The rise of XML spurred a wave of standard setting for data and protocols in almost every industry that continues to this day. Efforts like RosettaNet and OASIS are extending standards in every direction including the semantics of the data. Almost every standards effort is based on XML in one way or another. Enterprise applications use XML as a standard way of describing data, and EAI technology moves XML messages from one application to another. XML has also spurred the creation of a variety of toolkits for managing and transforming data stored in XML format. The result of the spread of XML is that conversations about standardization and integration are much more focused on what to do rather than how to do it.
While all these other developments are profound in their effect,web services is perhaps the most significant. It is the catalyst that allows Enterprise Services Architecture to spring into being. Web services are like a universal plug and socket system that allows applications to describe and implement different ways to communicate with each other. Unlike CORBA or DCOM and other previous attempts at thissort of connector technology, web services are based on XML and truly platform-independent protocols such as SOAP. Like HTML and XML, Web services are also simple and flexible. Web services technology has become the default interface to application components and services. Web services are simple and universal enough that the vast majority of the participants in the IT universe are convinced that all applications will eventually be able to communicate with each other through web services. This simplicity has become aproblem as its popularity has outstripped its maturity. Some basic definitions for security, guaranteed delivery of messages, transactions, and other portions of the standard are still being defined. These gaps do not obscure the fact that, like XML, web services have changed the conversation about application integration to focus more on the goals than the methods.
One development that is still more a hope than a reality is the emergence of a strong consensus around the creation of languages to describe business processes. IBM and Microsoft combined their separate long-standing efforts toward business process modeling to create a common language called BPEL4WS, which merges the bestideas from both companies. SAP has signed on as an author of the standard and many other leading technology vendors also endorse BPEL4WS. Similar efforts called Business Process Modeling Language and Web Service Choreography Interface are also under development. These languages could become a standard way to describe the orchestration of components and services and the foundation for portable descriptions of business processes. The largest benefit accrues from these efforts if one of these languages becomes the standardized way to control the behavior of enterprise applications, which would allow tremendous configurability and interoperability.
With all of this infrastructure in place,including a complete set of functionality from enterprise applications and platform component systems, standard ways of describing data and interfaces betweenapplications, and even possibly a method of orchestrating the behavior of multiple components, Enterprise Services Architecture is now a practical possibility. The amount of work required to achieve a better architecture has become manageable.
About the Author
Dan Woods, a seasoned CTO, has built technology for companies ranging from Time Inc. New Media to TheStreet.com. He has managed the product development cycle from initial requirements through sales for web sites and software products designed for the publishing and financial services industries. Dan has also navigated all phases of the business cycle: crafting strategy and budgets, building and managing large development teams, writing patent applications, negotiating large vendor agreements, operating data centers, communicating with board members, raising money, and selling and marketing a product. Dan is the author of two books and a frequent contributor to InfoWorld and other publications.
 |
This material is from Chapter 1: Concepts and Philosophy from the book Enterprise Services Architecture (ISBN: 0-596-00551-2) written by Dan Woods, published by O’Reilly & Associates. |
To access the full Table of Contents for the book.
