2.1. What attributes must ESA embody? You may be saying to yourself, "Well, all of that sounds thoroughly daunting, and no one would disagree that IT, like all segments of the business, could always do better. But how do we address these challenges?" For most of the rest of this book, we will thoroughly explore the nitty-gritty details of ESA from the application and technology perspectives. In this chapter, we will examine ESA from a business perspective, and from that vantage point, any IT architecture that hopes to improve upon the existing IT architecture (such as it is) must have the following attributes:
Flexibility Here it is again. Ripping out a generation's worth of monolithic enterprise applications only to replace it with another one isn't going to reduce anyone's TCO or simplify any CIO's life. More than anything else, the next architecture must find a way to free data and functionality from siloed applications, package them properly, and put them at the service of processes. The way forward, at least at a granular level, is already clearthe concept of web services , which SAP, Microsoft (.NET and Indigo), IBM, and a raft of smaller software companies have embraced. Web services carve interoperability from enterprise applications that you can call remotely from anywhere using fairly simple exchange protocols such as SOAP. Web services defined without a process context are usually too granular to be useful on their own, but when designed as enterprise services with specific processes and process steps in mind, they accomplish the necessary task of transforming powerful, albeit static applications into dynamically available functions flexible enough to be used and reused repeatedly. In practice, this means that all of the function calls that comprise, for example, the order to cash business processthe ones involved in time to transparency, which we mentioned earlierare extracted from their respective silos and are loosely coupled in an end-to-end process that mirrors the real-world business logic. The addition of business semantics e.g., standards, compliance, interfaces, and documentation for data exchange between two business processestransforms a web service into an enterprise service, a marriage of technical and business standards that didn't exist in previous architectures, as illustrated in Figure 2-2. Figure 2-2. Business semantics needed in addition to SOA  The combination of business semantics and an SOA, which can loosely couple and decouple technical functionality as needed, results in ESA, which is the framework needed for the positive evolution of IT. Instead of enterprise applications shaping business processes from the inside out, knowledge workers at every level can contribute to and help shape IT around real-world scenarios and business processes from the outside in. That also requires ESA or any other architecture to possess...
Simplicity, or at least enough simplicity to be understood outside of the IT domain If the current IT architecture has one flaw that's more fatal than the others, it is the tremendous amount of complexity involved in integrating combinations of enterprise applications into a coherent operating environment to automate emerging process needs. This difficulty drives TCO and the number of developers on the payroll higher, and it drives managers crazy. This shortcoming also drives the popular perception of IT as the obstacle on the way to innovation. To transform IT into an enabler of growthand this is at the heart of ESA's promisea simple system is needed that moves control of the architecture out of the hands of IT and shares it with empowered employees on the front lines of the business, the ones who need IT to support their attempts at process innovation.
Traditional development techniques, even using languages such as Java and ABAP, have improved greatly over the years. However, applications derived from enterprise services can be developed faster and are easier to modify because the complexity is carved up elegantly across systems of loosely coupled services; it is not buried deep in a monolithic structure. To that end, the next architecture must be model driven. It must enable knowledge workers to create new scenarios or business processes that can be manipulated with graphical tools linked to the enterprise services below. To oversimplify a bit, businesses need a user-friendly approach to their IT investments. And that's what ESA's model-driven approach offers. This has an enormous impact in terms of control and distribution:
Control For the first time, the primary user of IT isn't an application consultant or an in-house developer, or even the CIO, all of whom will design, consciously or subconsciously, an application according to their interface preferences and (incorrect) assumptions of what line users need. That is why so many of the first generation of enterprise applications reflected the structure of the database, not the model of the business in the user's mind. Instead, a new kind of architecta manager who is intimately familiar with the day-to-day workings and needs of her operational business unitwill use modeling tools to design new scenarios as needed. And she will be able to adjust these scenarios virtually, on the fly, in response to changing business conditions instead of having to rebuild them in 18 months at a cost of millions of dollars. We will discuss the business analyst role in detail shortly, but it's important to note here that business analysts will not constitute a new mandarin class within the enterprise; they won't be replacing one institutional bottleneck with another. They will organizationally embody another key attribute of next-generation architecture, that of...
Distribution By liberating enterprise services from monolithic applications, and by allowing assembly of these services by business analysts and beyond, ESA creates the possibility of increasing automation at every level of the business, scaled up or scaled down, depending on the person's place within the enterprise. This is the role-based approach to IT, a vision in which business analysts create semitailored roles (for a customer service representative, perhaps, or a factory shop-floor manager) which are basically portal interfaces to a predefined set of data and functionality that helps that role carry out the tasks needed to support a specific process. (As we will see in our discussion of the user interface (UI) throughout this book, a new pattern called the work center provides a reusable, role-based structure.) In this way, business analysts can decentralize the power of enterprise computing, enlarge the population involved in adaptation and innovation, and increase efficiency across the business by empowering employees with just enough functionality.
And that's just within the company. Perhaps the greatest potential within the enterprise services concept is the idea that selected data and services can connect on both a technical and a semantic level outside the boundaries of the firm to partners, suppliers, and customers, each of which can pass and receive data to drive decision making at either end. Each of these attributes underscores the overarching need to unlock the power and value already residing in the previous generation of enterprise applications. But once you have that power, where do you start? |
