Rick Sweeney is author of the recent book, Achieving Service-Oriented Architecture: Applying an Enterprise Architecture...
Approach (Wiley, June 2010), and the former chief architect at Blue Cross Blue Shield Massachusetts. He is an active advocate of SOA in the health care domain and in the SOA management vendor communities. In Part One of this two-part interview, Sweeney discusses an architecture-driven SOA paradigm, and what's been holding back adoption of this type of approach. In Part Two, Sweeney will discuss the cultural, organizational and operational impact of an architecture-driven SOA, and why the SOA architect needs to step up and lead.
What is an architecture-driven SOA paradigm?
Sweeney: They didn't call it SOT for service-oriented technology. They called it "architecture" for a reason; it needs to be strategic, not tactical. It needs to be top-down vs. bottom-up. It needs to start with the top-level constituency vs. the bottom-level application. "Architecture-driven" is an initiative from the overall business architecture tied to the physical architecture; it's not necessarily a project delivering an application. Most SOA projects probably have very little defined in terms of what was delivered in the context of business/reference/physical architecture.
Business architecture is a conceptual representation that identifies constituents like customers, vendors, customer services reps, using specific channels, be it Web, or portal … to gain access to businesses processes like place an order, which consumes services like look up customer credit, for example, that integrate with the back-end system. Business architecture is a new framework, a new way for the business to document and specify needs from a top-down view of what is being delivered to whom.
Parallel to that is the reference architecture, which says these constituents are defined in terms of their profile in our identity management system; and the roles for access to services are defined in our access management system; and the access points are through the customer portal, etc. When you go into the design phase you can look and understand that a customer portal exists, that a definition of customer constituent exists. If every component in every layer has to be built from scratch, [the project is] this scope; but if you look at delivery with existing services it has a lower price point. If you look across multiples initiatives—both sales and customer service want to deliver this stuff through a customer portal and it would be nice to consolidate up into one deliverable—that's where an architecture-driven paradigm shift occurs.
What is an EA approach to SOA?
Sweeney: The real issue is that the traditional way business thinks/defines/scopes/funds IT requests has been institutionalized based on monolithic stovepipe solutions; and the way IT and the PMO work has all been institutionalized. All three of these work against the concepts of SOA; and they're all barriers to driving a holistic approach to SOA.
My book describes how to put together a SOA business plan … the plan is not about 'we're going to deliver these solutions in this order,' but about how we need to change our people skills, the processes we use, and the practices around architectural skills for developing frameworks, so when we do this business initiative we've got the right people, process, practices and platforms. [And] this is how a governance practice should operate; this is what the SDLC should look like. Take your current environment and do a gap analysis. Identify gaps and action items.
You say architectural restrictions have slowed SOA adoption—can you explain?
Rick Sweeney: Few companies have developed a portfolio of development frameworks and standards applied when building SOA solutions. The solutions … weren't designed in the context of a larger SOA picture. They didn't address issues like personalization and exception handling as design tenets. SOA is not just Web services; the things that have been built are more inquiry or one-way data delivery. When you get into more complex transactions and business processes, the fact is you have no frameworks on how exceptions are handled, how logins are handled, [etc.]; you have to dig into the bowels of each service to find out, so you end up with multiple logic mechanisms and so forth, because all the decisions made were for each implementation. Architecture is the missing component slowing the adoption of SOA.
In the book I talk about development frameworks and design patterns for SOA. Like a framework for personalization, like language preference, or a framework for how to authenticate a user's right to use. Each service should able to understand and apply the attributes of a design framework. These are the kinds of frameworks missing in most environments that cause services to be built standalone vs. a holistic enterprise-level solution.
For more information about the SOA Enterprise Architecture Framework (SOA-EAF), see Sweeney's SOAIsTheWay blog.