Approach to Strategic SOA

At this point, let us not get stuck with what is a symptom of Integration projects more akin to traditional EAI enabled through JBOWS (Just of Bunch of web services) but focus more on how we achieve strategic SOA visioning and realization. In more than one sense, this approach is what Enterprise architects have taken to create business IT alignment over the years – create a portfolio of services which link future and current business to IT systems using a first class notion of services in SERVICE PORTFOLIO PLAN. I refer to the phrase – In more than one sense – as many EA practitioners have always focused on several notions which are part of SOA driven Service Portfolio Plan. Till recently (about 6 months back), many EA tool vendors refused to create a suitable first class construct for services, which has now emerged e.g. Telelogic system architect 11.x or ARIS IT/Business Architect 7.x, but now that you wonder looking back – as an EA practitioner, you felt that the missing link between business and IT applications was always something which we filled in with capabilities or an equivalent word – now we have a software construct which we call service to fulfill that real gap.

Coming back to service portfolio plan – this is a combination of several artifacts – and to give a high level content overview of the same, we delve into classic definition as described by CBDI forum and some of my comments on how this has been practically implemented in many organization.

An SPP is a list of all software services that will be needed to assemble solutions as per SOA principles. Creating a plan upfront has several benefits because we can establish case for SOA – understand what will be shared going forward, how do we reduce duplications in data/logic/capabilities, how do we plan to aquire them and how will they be laid out in IT landscape by time/infrastructure/technology etc.

First and foremost using very well proven techniques of compartmentalizing processes, business types and organization roles into Business domains is done for an organization. In my earlier life starting EA, my ex-company used to refer to them as Business Components – Large coarse grained collections with very little dependency between them. In practice, it is possible to split an organization into 10-18 (typically 12-13) such chunks.

Before we barge into identifying services within each business domain, we spend some time definition key policies/tactics:

1. At what level do we intend to specify services – all its crowning glory now or we sketch the services list at one go and leave for a project to come in before we really sketch it out in completeness per domain as a later stage (recommended practice as you can die doing complete service/ operations and their specification list)
2. How do we want to aquire services – commercial decisions aligned to IT Gov/arch policies
3. How to certify/ reuse the services
4. Governance rules
5. Architecture and Layering policy – example was shown above – you may want to hedge bets on something like Microsoft Motion, IBM SOA method, OASIS recommendations as well.
6. Service lifecycle tooling support – which tools/standards are used to store requirements, design time, validation and runtime of services

The services within each business domain will then have a service view which depicts there specifications in far more details than is indicated by a WSDL i.e. transcending typical I/O and end point type of stuff – but be more focused on how business owner is, what is the service representing in portofolio layer, QoS spec etc. The similar spec is applied at operations of services. Upstream linkages (to business processes or higher layer of services) and downstream linkages are created.

The services are mapped to technology that will create implementations for the service operations.

Technologies are then shown deployed on infrastructure – servers, data centers, devices, network – by various environments in implementation views.

The service to solution view is deliberately kept out of these views and is left to solution assembly teams to fulfill.