SOA and Reuse
In a two-part podcast series, Dave Berry from Oracle’s Fusion Middleware team and Mike van Alst, a consultant with IT-eye, discussed some remarks I made in an earlier OTN Arch2Arch podcast regarding SOA and reuse. Specifically, I tried to de-emphasize the reuse aspect of SOA. Many reuse programs that I’ve seen or read about have two key elements:
- Building things in a reusable manner
- Making those things visible
While noble goals, these approaches are at significant risk of producing the intended results. The first item has a fundamental problem in that it is all but impossible to define exact what “building in a reusable manner” is. We can use open, interoperable standards rather than closed, proprietary ones, but is this the key barrier to reuse? There’s probably some low hanging fruit that this will capture, but there’s so much more to reuse than this. From a technical standpoint, one must also consider the structures of the information being exchanged and the varying granularity of the information being exchanged, among other things.
On the second item, visibility is important, there’s no doubt about it. But visibility without context will not be successful. It’s a matter of providing the right information at the right time. Too many initiatives that are associated with the collection of IT artifacts, be it reuse, SOA, portfolio management, ITSM, or any of the like, fail because the information is never put into the context of the processes that need that information. How many times have you seen the information collected as part of a fire drill for an immediate need, only to grow stale once that fire drill is completed.
The two things I recommend are service ownership and linkage to key IT processes. If you’ve heard me talk on panel discussions at conferences, you’ll know that my answer to the question, “What’s the one piece of advice you have for companies adopting SOA?” has always been, “Define your service owners.” Someone is given the responsibility for a functional area, providing capabilities to the rest of the organization and accountable for driving out the redundancies that may exist. This is a tricky exercise, because service ownership has a cost associated with it. Expending that cost for a service that is only used by one consumer can lead to waste, so it’s not a silver bullet. It does, however, being the cultural change from a project-driven organization to more of a product-driven/service-driven organization. Without having someone accountable for the elimination of redundancy in a domain and serving the needs of consumers, it won’t happen.
The second piece of advice is the process integration. To avoid creating repositories that see infrequent use after initial population, you have to define the role of that information in the IT processes. If you have a service repository, when do you expect project architects and designers to look into that repository for services that may be appropriate. How about it the strategic planning process? The scoping effort for a project likely begins long before a project architect is assigned? How is the service repository used in those activities? By defining the links with key IT processes and ensuring that those processes are changed to use the repositories involved, with appropriate governance to make sure those changes are occurring, you will make sure that your services are visible, and more importantly, that the right people are looking for them at the right time.
2 Responses to “SOA and Reuse”
Leave a Reply
Todd –
You’re hitting the nail on the head here. The fundamental challenge is describing the portfolio of service assets in a succinct and ‘grok’able way. Once an organization builds all this wonderful fully integrated best thing since sliced bread service portfolio, then what? Reuse is not a technical challenge, it’s a challenge that requires organizational capabilities:
i. Creating the appropriate translations to allow potential consumers to find what they are looking for in their language
ii. Creating the appropriate translations so potential consumers can properly leverage service assets
iii. Creating the appropriate incentives to spur adoption of service assets
iv. Integrating appropriate tools to allow all of this to occur in a scalable way
I think I just described the gist of what the “Capability-Based Analysis Transformation at the DoD” white paper / case study tackles. Reuse doesn’t just happen, despite some of the more unrealistic expectations in the technical community!
Regards,
Aleks
Todd, Aleks,
Would concur with all the items stressed. I think reuse happens while executing what the both of you have articulated. As a functional owner of a pallet of services becomes the enterprise SME the reuse evolves, this is what I have experienced. Then getting those functional service experts/owners early in the planning process of all those “projects” seems to be a huge challenge, critical to consolidating services, and really a significant factor of project management process maturity.
I think the Chief Architect needs to take responsibility of ensuring these capabilities, ownership, and linkage to processes happen. Although we can all agree as enterprise architects this is what we need to have happen, it takes some executive leadership driving from the top (along with their peers), with grassroots efforts happing at the bottom to get it done.
I think in the broad scope of technology professionals many know the patterns, what needs done, and have a huge pallet of technology, however, struggle with how to make what both of you articulated actually happen within our organizations. This is the hard part, and it comes down to some really strong leadership, with a healthy amount of integrity.
Cheers!
Tom