Thomas Mattern: First, businesspeople consider the architecture to be technical and complicated. Enterprise SOA isn’t only about technical aspects; it’s about “architecting the business” and improving how business processes run. Second, people think enterprise SOA is something proprietary from SAP. It isn’t; it’s a concept that SAP’s products are based on, but it’s not proprietary. It’s founded on open standards, both technical and business.
Dan Woods: I think the biggest misconception is thinking that you can’t start with small projects and learn by doing things incrementally; you can. Enterprise SOA is friendly toward incremental learning because of how the services let applications coexist. For example, start by using enterprise services that are available as part of mySAP ERP and then add in specific business processes such as electronic bill presentment and payment (EBPP).
Another misconception is that enterprise SOA is overwhelming, impossible to understand. The thing is you can do small projects in the spirit of enterprise SOA; using even a couple of services can make a big difference.
Usually, when you think of SOA, you think about the technology of creating services. SOA implies a huge amount of development, but that doesn’t need to be the case. Most SOA vendors talk about how great it is to use Web services — you get all this flexibility — and they never answer the question of where the services that connect your core applications are going to come from. Enterprise SOA provides the answer as to where those services come from. They come from SAP service-enabling its applications and making those services available in the Enterprise Services Repository (ESR), a directory of enterprise services.
NWM: Enterprise services are, of course, business-process-oriented. How does this change the way business and IT build their ERP systems?
Woods: The first enterprise applications in the late 1960s and early 1970s were about data and keeping track of it. The business process existed, of course, but it was represented by data. In time, that database grew, and recorded and modeled more activities. Instead of just modeling the financial state, the data began to describe the state of the process. Now, applications focus more on the process than the database. This is a big switch. Enterprise SOA provides the plumbing for IT applications to accurately model the processes.
Mattern: This is a complete paradigm shift. The development challenge of the 1990s was to determine whether we should buy software or build it. Today, we build and buy, and we compose applications. Composite applications (xApps) are major drivers of enterprise SOA; they don’t exist without services. They use services to connect to data inside existing systems. When new applications such as Duet and SAP Analytics come along, everyone developing them follows the paradigm of xApps. Naturally, new roles evolve that focus more on model-based composition than on writing fourth-generation language (4GL) code from scratch.
NWM: SAP is encouraging its customers to start on an enterprise SOA roadmap. What advice can you offer them?
Woods: When SAP NetWeaver arrived, the message was, “Think big; start small.” Think big: Think about your architecture, think about where you’re going, think about what you want to do. But start small: Do things that have value; find the low-hanging fruit. The roadmap is just an organized way of applying that advice.
Mattern: When SAP announced its first enterprise SOA roadmap at Sapphire ’04, Henning Kagermann, CEO of SAP, explained that SAP had a three-year roadmap — 2004 through 2007. Immediately thereafter, companies began asking, “Do we have to wait until 2007 before we go to full service-enabled SAP software?” Clearly, they should not wait until 2007. They should start with products that are already service-enabled. For example, today mySAP ERP uses more than 300 enterprise services.
NWM: We see a trend in new titles, such as enterprise architect and business-process manager, that started before enterprise SOA, one where companies are involving business more in the IT planning process. How does enterprise SOA change that?
Mattern: On the highest level, we see a transition from CIO into two distinct roles, chief process innovation officer (CPIO) and chief IT officer (CITO). (See “Meet the New CIOs,” SAP NetWeaver Magazine, Summer 2006.) The role of enterprise architect has evolved without enterprise SOA (see “Meet the Enterprise Architects,” SAP NetWeaver Magazine, Spring 2006). However, the skill set of the enterprise architect is changing. Most companies have the role of enterprise architect, with or without the title and skill set required to build tomorrow’s IT organization. Enterprise architects need a broad, comprehensive view in order to align business and IT; the business side is often missing. Conversely, businesspeople know the processes, but aren’t familiar with IT. The new roles have to look at both.
Woods: Enterprise SOA defines who’s doing what, which roles are involved, and who’s responsible for it. SAP provides both the tools and the services. That’s the differentiator: a model in which IT and business rules change. Enterprise SOA explains how the rules change. Business analysts can now create applications and adapt solutions to their own use. IT creates the services others reuse. The roles needed include: repository keepers, who maintain the directory and help define which services are needed; disruptive innovators, who find new ways of solving problems; composers, who create applications out of services; and consolidators, who reduce the IT infrastructure’s cost and complexity.
How will the rest of the community interact with the main architect to evolve new services and collaborate on service development? SAP drives a whole Enterprise Services Community (ESC) in which independent software vendors (ISVs) and users can propose services to be developed collaboratively. The scope of services included in enterprise SOA includes both SAP and third-party solutions.
Mattern: The idea for the ESC is to form industry groups so SAP and its partners can work together to specify the requirements and parameters that enterprise services require. The partners help us productize those enterprise services. ISVs, for instance, build enterprise services in the application space, most likely as xApps.
NWM: A lot of companies following enterprise SOA are asking, “Is the timing right for us? How do I know when I should do this?” What advice can you give these companies about when to look at enterprise SOA?
Mattern: They should start today. Don’t wait until the whole world is service-enabling and then start. Build roadmaps. Make plans organization-wide, and start today with products that are already service-enabled, such as SAP Analytics and mySAP ERP 2005. SAP NetWeaver is the technical enabler for enterprise SOA. Companies need to become SOA-ready now.
Woods: Every company has different systems that fall into three general categories: first, stable systems, such as mainframe systems, that don’t change much; second, flexible systems that change within, say, a two-year timeframe; and third, dynamic systems, which are usually the ones providing core productivity for collaboration or core differentiation for product delivery. SOA is needed because your dynamic systems can’t keep up with your business changes. The more business priorities wait for IT implementations, the more you need enterprise SOA.
At Sapphire ’06 in Orlando, all attendees received a copy of the book Enterprise SOA: Designing IT for Business Innovation by Dan Woods and Thomas Mattern (O’Reilly Media, 2006). Dan Woods is the CTO and editor of Evolved Media NetWorks, a content creation and editorial services company. Thomas Mattern is a solution marketing manager at SAP and focuses on enterprise SOA and how to get to it. We asked the authors to discuss the enterprise SOA concept and how businesses might approach it.