As professionals in the enterprise architecture field, we have observed the recent and spectacular rise of the concept of service-oriented architecture (SOA) with excitement tempered by concern. The new standards-based architectural paradigm promises great advances in interoperability among previously incompatible software applications. In turn, it has the potential to deliver gains in agility and IT cost control. Perhaps most exciting, though, is the potential for SOA to make possible the realization of event-driven architecture (EDA), an approach to enterprise architecture that yields a high level of agility by increasing systems’ awareness and intelligent responses to relevant events.
At the same time, it became clear to us that the steps required to design and deploy an EDA, or an SOA, its master set of architectural characteristics, were far from obvious. Even going beyond the fact that the technology and standards are immature and, thus, challenging, the practice of uniting software with an overarching standards-based approach that extends outside the enterprise is a new field, lacking in many of the guiding principles of infrastructure, governance, and best practices that hold together most traditional forms of architecture and development.
For better or worse, some software vendors are now bringing what they call EDA suites to market. However, the commercial offerings in EDA tend to be quite narrowly defined and vendor-centric. As such, they are inadequate on their own to offer much in the way of instruction on the overall best practices required for EDA.
We perceive a need among architects for a book that combines both the theory of EDA—the grand vision that led to its formation and the essential nature of the paradigm—with a practical look at building an EDA over an SOA implementation in the real world. This book is neither all theory nor all practice. It is a blend, with the idea that true success with EDA depends on a good understanding of both aspects of the paradigm.
To understand how this book is set up and what it contains, we thought it would make sense first to take a quick look at the definition, history, and context of EDA and SOA. These two related architectural styles are not as new as they seem, though recent developments in standards have led to breakthroughs in their potential realization.
Even for a lot of experienced architects and developers, the implicit connection between EDA and SOA has not been intuitively obvious. A lot of IT pros react to SOA with a sentiment akin to, “That’s really cool. Now what?” These questions are completely legitimate. Imagine someone handing you a violin and declaring, “Oh, good, now I get to hear Mozart.” That person is making several assumptions, including that you know what the violin is, how to play it, and how to play Mozart in particular. In many IT situations, it is not always evident how loose coupling and a service orientation will take you to an EDA. If your boss drops a Visual Studio 2008 pack on your desk and says, “Now you will deliver an EDA,” you might not necessarily know how to get from here to there. That is the purpose of this book.
Much of this book is dedicated to helping you understand where the rubber meets the road in turning the vision of EDA into a reality. In so doing, we delve into detail on the subject of SOA, providing the essential building blocks of the most versatile and effective EDAs. We address one of the great unanswered questions posed in the wake of SOA’s high-profile arrival on the IT scene: How do you actually get to the achievement of business goals that EDA enables using the actual technologies that make up SOA? The leap from Web services and SOA to the fulfillment of EDA, and its attendant agility and IT cost savings, requires some serious discipline.
This book consists of two parts. Part I, “The Theory of EDA,” covers the theoretical aspects of EDA. The path to EDA, which we guide you through in this book, starts with an understanding of what EDA is. Part I begins with a thorough theoretical definition of EDA. We cover the core components of EDA, such as event consumers and producers, message backbones, Web service transport, and so on. We also describe the basic patterns of EDA, including simple event processing, event stream processing, and complex event processing.
From this definition, we then explore the current context of EDA, which is the jungle of interoperability challenges that we all face in large enterprises. Having thus set up the situation that we face—we want EDA (or at least, we should consider it)—we see how difficult it can be to attain. Enter SOA, and its open interoperability, which paves the way for the realization of EDA.
In addition to defining EDA, we explore the SOA-EDA connection in depth. In our view, any serious attempt to develop an EDA today will rely on the use of SOA technology as it is emerging in the marketplace. The EDA of tomorrow will run on Web services and enterprise service buses. The EDA components—the event producers, consumers, and processors—will all be Web services. We will flesh out this vision of EDA.
The conclusion of Part I consists of examples of EDAs and how they might function. We explore examples of how businesses and other organizations might ideally use EDA to further their objectives. This set of examples provides a transition to Part II, “EDA in Practice,” of the book, which moves you into the reality of EDA and how it might be approached in an actual enterprise setting.
Part II begins with Chapter 6, “Thinking EDA.” This chapter explores ways to identify the ideal use of an EDA, or a partial EDA in realizing a set of business objectives. Chapters 7 and beyond present a set of case studies of EDA. Some of these case studies are based on real companies. Others are partially hypothetical, but based on real-life experiences we have had in the world of enterprise architecture.
In each case study, we describe the organizations involved as well as the technological and business challenges and objectives that they have. We look at the ways in which the business and technological situation would benefit from an EDA approach. We look at the practical issues that arise in its design and implementation. Our goal is to include, where relevant, some organization and non-IT issues, such as project management and communication. Of course, we get into depth on the technologies required to birth the EDA.
Throughout the case studies, we look at a number of related topics in the field of enterprise architecture that have relevance for learning about EDA. These include SOA infrastructure, governance, and security. Wherever possible, we try to point out business issues that are relevant, but perhaps not apparent to the technology reader, as well as technology issues that might not be noticed by the business reader.
One of our other goals is to instill in you a good sense of when to use an EDA approach and when not to, for the paradigm is not a panacea for all IT and business problems. This issue reminds of the story of a man who once approached a famous surgeon and said, “You make more money in a week than I make in a year. I don’t think it’s fair. Is what you do so special?” The surgeon replied, “Surgery itself isn’t that complicated. I could probably teach you to do it in a few weeks. What takes the training and skill is knowing when not to operate, and what to do when something goes wrong. Learning those two things can take years.”
So it is with EDA. Developing a Web service is not hard for an experienced developer. Knowing how to use the functions of an SOA to create an EDA, though, is another matter. And, like the surgeon, you would be well served by understanding when to use and not use the EDA approach. If you take away nothing else from this book, consider that there are many cases where an EDA is not the optimal solution to a business issue.
If you’re holding this book in your hand, you are probably involved with information technology. If you are not in technology, we really admire your desire to be a broadly informed citizen. We have written this book in fairly deep, but not excessively detailed, technical language.
This is not a book that is awash in code or extensive jargon. We have made the choice to skip the deep, deep techie language because of the likely blend of readers that we expect to find. The subject of EDA can be of interest to the work of a vast audience. EDA itself is an area that is inherently interdisciplinary. EDA naturally throws together developers, line-of-business people, IT managers, security specialists, architects, and network operations people. There is probably a whole EDA book for each of those disciplines. Luckily for us, someone else will write them. We want to present the topic in a unified approach that a multiplicity of readers can absorb.
Our other guess is that you probably work at a large organization or with an entity that interfaces with large organizations. Whether you work at a corporation, public sector organization, or educational institution, the issues for EDA are the same. We come from the corporate world, so we have a tendency to talk about “business value” a lot. If you can’t relate to this, we are sorry, but for stylistic reasons we need to use just one measure of efficiency, and in our world, that measure is usually dollars. So, when we talk about “business value,” we mean the economy of effort required to produce a result. It’s a concept that can translate into any organizational agenda.