Kerrie Holley has been an integral part of over fifty separate SOA projects in roles ranging from Designer to Chief...
Architect. He holds several SOA patents. In his current role as an IBM fellow, Holley oversees the technical direction of hundreds of SOA projects. His current focus is increasing business flexibility through the use of business rules, BPM, analytics, and of course SOA. Toward that end Holley and his compatriot, Dr. Ali Arsanjani, have written a book called "100 SOA Questions Asked and Answered."
SearchSOA.com got the chance to talk with Holley about the book and ask him some questions of our own. This is the third part of that interview. In Part One, we talked about SOA methods and identifying services. In Part Two, we'll discuss how agile methods and object-oriented programming fit in with SOA. In Part Three, we'll be looking at IT infrastructure, best practices, and more.
A big SOA question concerns methods. Focusing on methods, what changes in systems development result from SOA?
Kerrie Holley: I look at SOA as effecting methods across the lifecycle. I think that SOA is an incremental addition to methods, and not that it rewrites methods, that's point one. Point two – I believe that based on the value propositions you want to achieve you will adopt methods that are very specific with regards to SOA – especially for organizations doing business transformation to lower cost of ownership or accelerate time to market. Others will take a more piecemeal approach to change and maybe they're going to focus on reducing the requirement cycle. A lot of organizations are trying to change the development lifecycle in some particular way and that change requires methods specific to that particular change.
Let me jump back and give a preface on methods. I wrote [the chapter on methods] for two reasons. One is that I think we need to fundamentally change the lifecycle of how we build software systems if we wish to gain some of the benefits that SOA brings about; the second reason is that the way we build enterprise based software systems today is broken in the sense that the total cost of ownership of applications is rising considerably and the ability to adapt applications to changes once they been put into production is highly constrained. And these are both show stoppers for organizations that are trying to be adaptable and flexible.
The chapter on methods addresses those problems. How do we build applications where we engineer the applications to change? How do we build applications such that our total cost of ownership decline over time, so that we can put more dollars into investment and into new projects.
Question 41 asks "How should services be identified or specified to maximize reuse?" Tell me, what are the principal techniques for identifying services?
Holley: In terms of how we identify services, there are several ways to do it, but one way is to look at the enterprise and at services from a process standpoint. In terms of looking at the portfolio or the process model and deduce from that the actual services that can provide value. That's one way to look at it - to look at the actual services themselves.
A second way is to identify services from goals. We can look at the goals an organization has from the imperative and particular goals that an organization intends to fulfill.
The other way to look at the identification of services is to look at the process level variations that services have and to identify services from that. We can look at information and identify services based on that.
So there are multiple techniques that we recommend to be employed in parallel. And with those parallel techniques we look at things from the top down and from the bottom up. We look at existing assets, we look at goals, and we look at process models. Part of looking at existing assets is looking at existing data models that might add to that identification. We talk about domain decomposition, asset analysis, and goal service modeling.
Domain decomposition is basically looking at a process model; goal service modeling is tying your strategic imperatives to what you're actually going to do, so you don't wind up having to identify a whole slew of services. Instead, you can identify a single service and tie that to a specific goal. And then you can prioritize that and decide "…this service could be built four years out, but these services should really be built now." In Asset analysis you look at the extend/build/buy paradigm, where you look at what you already have today and look to extend that or to leverage it.
The processes you were just talking about, are those business processes?
Holley: When I use the word process, it's synonymous with business process, but at the same time there's a perspective that some processes lend themselves to modeling as business processes and some processes can't be represented in a diagram… So yes it's a business process, but it doesn't have to be represented in a process diagram. It could be represented that way, but we could also represent it in a number of other diagrams as well.