Steve Jones wrote:
> 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.
Yes, I think I do have a different WHY.
Here is a list (not exhaustive or mutually exclusive) of business aims
whose realisation may entail an SOA effort (these are examples of *my* WHY):
* Increasing business agility (ease with which business processes
can be changed)
* Reducing complexity/fragility in the IT applications landscape
* Facilitating or preparing for migration of application platform
(e.g., to a package)
* Rationalisation of services (reducing service redundancy)
* Reducing cost
* Increasing automation (i.e., reducing manual exception handling)
* Enabling disaggregation of service provision (i.e., enabling
outsourcing)
* Enabling internal services to be offered externally (commercially)
* Expanding or reducing the portfolio of services
* Realising synergy benefits (after merger or acquisition)
* Aligning applications to interface/choreography standards
* Increasing the scope and/or extent of automation of e-commerce or
workflow
* Aligning IT to a business process re-design/re-engineering
* Increasing business volume capacity
It is unlikely (and I think unwise) for a business to try and achieve
all of these in one exercise. I think that the way you conduct an SOA
exercise (what you do, how you do it, who should be involved) will be
different depending on which of these are driving the effort. This means
that you need to understand the business drivers you are trying to
address before you start.
I agree that your WHY is needed too, but for different reasons.
> 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.
Excellent -- I think that would help.
Rgds
Ashley
