2009/1/10 Ashley at Metamaxim <[email protected]>: > Steve Jones wrote: > >> Well my trite answer is "b(u)y my book". My longer one is that for me > these have _always_ been what >> I've seen as the services and the job of IT is to deliver as > appropriate to that service. > > Well, I took your advice and read your book. It has lots of good stuff, > and I agree that SOA must be business driven. > > Here are some thoughts: > > 1. I think that a prerequisite for any "service architecture" work must > be an understanding of the need for (or possibility of) change to the > business, and at least some consensus on what such a change might be. > Moreover, there must be a credible story that SOA can be the path to > achieving this change. In other words the business WHY should be first, > not third as shown in the diagram on page 10. Otherwise I fear there > will be a lot of senior level people in the room saying "Why are we > doing this?"
>From experience you don't want to start there as you need something for the "Why" to be attached to. In terms of how long it should take. If you have a decent set of people then a given Level model should be done on a whiteboard in a couple of hours, including WHAT, WHO, WHY. The reason to do WHAT and WHO first is that these are the services and it is their interactions (WHY) that will drive everything onwards, if you start with WHY you tend to get either a list or (even worse) a complex process model from which you have to refactor the "real" services. > > 2. The approach described in the book for defining an enterprise service > architecture is essentially one of "top-down decomposition". However, I > suspect that structure of services for a given business is probably not > unique, and its form will depend on the business rationale (drivers) for > undertaking the whole exercise in the first place. This is another > reason for putting the WHY first. Maybe you have a different WHY to me, but these WHYs are "Why does X interact with Y", so the shareholder interacts with the business... WHY.... to gain money from their investment. You really need the two ends first. Now remember your top level picture is often going to be a single service (e.g. VMI) and it will have two actors (the Vendors and the retailer/manufacture/etc). WHY are the vendors involved? Sales & predictability. WHY is the retailer involved? Stock outs, profitability, reduced costs. It isn't like you wait four years to do the WHY bits, its just that you do the WHAT and WHO so you know where the WHY is coming from. A WHY without an owner is death as it becomes an unhinged driver. > > 3. I was concerned that the definition of service too vague. The > examples of Level 0, 1 service maps looked to me much like traditional > functional decomposition diagrams. Is there any difference, at this > level, between a "business service" and a "business function"? At the > bottom of page 57 there is the rather alarming suggestion that > "Customer" can be viewed as a service. I would be concerned about > attempting to create a service architecture without a clear idea of what > can qualify as a "service". Customer is, in most cases, a service. After all it has capabilities, it has a defined way of interacting and you can get an RWE when you interact with it. Just because its not YOUR service doesn't mean it isn't a service. I will admit however that if I write a new version then I would be more formal around the service definition pieces and I have been in some of the recent application portfolio strategy work I've been doing. If you've done some BPR work then some of this will look similar, the difference is that the decomposition is always one of containment its never one of steps (which is an important difference) but being blunt what I've done is just distil down some complex business modelling approaches into their core and say "this is the bit that really matters" because all too often those powerful bits are then replaced with complex models which are great in their own way but understood by very few and don't enable cross boundary interactions to be done effectively. > > 4. I some ways, what you describe looks like a methodology building a > business strategy. However, there are other considerations that need to > be included in the formulation of business strategy, such as: > - Best practices on the industry One of the things that I haven't managed to get work to release is the industry templates that we use as a reference point. Think of them like SAP Blueprints for an industry. > - Competitive position, opportunities and threats This is outside of the scope here but if you look at the heatmap pieces you can see how those sorts of things get factored in. I didn't want the SOA method to morph into this though. Interestingly what I've been doing since then around Application Portfolio Strategy does incorporate these sorts of things and its getting more important in this current climate. > - Assessment of corporate strengths, weaknesses and aspirations. As above. > I would think that these need to be considered in any exercise that > has an enterprise-wide scope and impact. I completely agree. What I tried to do with the SOA method was to give those exercises and others such as BPR, EA, Package implementation, portfolio strategy et al a common reference point. > > Notwithstanding these comments, I am quite sure that value is only > obtained from SOA by taking a business perspective, and driving the work > from a clear articulation of the business objectives is the only way to > succeed. Thanks for the comments very helpful. Cheers Steve > > Rgds > Ashley > >
