I had a chance to look at Forrester analyst Randy Heffner’s report on the best way to build SOA (via Joe McKendrick’s Forrester's Five-Step Path to Building SOA). Joe provided a link to the complete report, How to Build Your SOA Platform on ebizQ. Randy writes in the summary, “Building an effective service-oriented architecture (SOA) platform requires cohesive integration of both new product categories, such as SOA repositories and enterprise service buses (ESBs), and existing product categories, to which vendors are making many SOA enhancements.” He argues against a big-bang transformation except for the very wealthy, but also says an ad-hoc plan can be a waste of money. Instead, he suggests that the best approach is to “place tactical SOA platform investments within a planning framework for evolving a strategic SOA platform. If, along the way, you are able to justify large investments to accelerate your platform build-out, so much the better.”
Joe does a nice job of summarizing the five steps that Randy advocates: Identify existing infrastructure’s SOA capabilities, identify priorities for new SOA capabilities, identify your long-term needs for SOA capabilities, match your platform plans to your organization’s investment strategy, and evolve your SOA platform in line with the business value of solution delivery projects.
I wanted to address Randy’s opening statement, effective SOA “requires cohesive integration of both new product categories, such as SOA repositories and enterprise service buses.” Making this integration and transformation simpler is the goal of SOA Testing, Validation & Virtualization practices. In fact it is hard to get to the point of integration without conducting these activities throughout the full lifecycle of the application.
Randy makes a point that there is no one dominant way to build an SOA; companies might start with a specific technology like REST or SOAP or ESB in mind, but that isn't what drives the budget. Indeed it is a heterogeneous problem for any ongoing business with existing technologies to evolve to some future of services-based applications and reuse.
There is value in thinking about SOA from a strategic perspective, and we are big advocates of architecture and design driving selection processes. Before we start, we need to rationalize those existing and proposed technologies for relevance to the business needs and budget.
Now when it comes to articulating these Strategies into SOA Policy, this is where I really feel we have something to add to the discussion. The business-driven expectations of Performance, Scalability and Reliability (PSR) need a mechanism that can verify and enforce these Policies to ensure that they are being met. This needs to happen at the initial component level of design and development, as well as continuously at runtime.
But think about this concept a bit further -- why not Validate your expectations as part of the vetting and selection process for your design? If you could have an idea of the performance and logical correctness of using a suggested ESB or Service layer, you could recommend it as a next budgeted step in your SOA migration with a lot more confidence. The level of testing doesn't have to be prohibitively strenuous, but being able to verify some business logic and performance expectations of that candidate service early on would save plenty of time and money, compared to testing at integration time.
I certainly agree with Randy that SOA implementation needs to be a balance of strategic and tactical activities, and let's continue to think about how we can help with both ends.
Comments