I like this article from CIO magazine by Christopher Koch entitled The Starting Point for SOA. Sometimes in all the hustle and bustle of getting things done, communicating, pontificating, and generally pursuing EA and SOA, we forget the most important thing -- the why? Not the, it's going to save time and money why -- those are givens. The what will this mean to us and our clients why.
We've spent a lot of time recently trying to explain SOA and the implications on our business. I understand the opinion of some that you need not explain services and SOA to beyond IT, but in my humble opinion, that's simply hogwash. If you believe, as I do, that EA is just as much about the business as it is about technology, then you must equally communicate on both sides. Not necessarily about the same things of course.
This, we've recently been attempting to describe SOA as a set of layers to the business stakeholders in my organization. We're attempting to describe the new paradigm as a stack, with "Offerings" at the top, "services" in the middle, and "products" (content/deliverables/data... this works reasonably well in most cases for a library) at the bottom.
The take away messages being: Services (and orchestrations of services) can be used and reused in many offerings. We no longer want to build a silo through all three of these layers (offer, service, product), we want the bottom layers to be used amongst many offerings. This is efficient, this will , partially, enable a nimble and flexible enterprise with good alignment between IT and business desires.
The business value of EA only becomes truly clear (beyond simply
reducing costs in the IT infrastructure) when you begin to think of SOA
as a strategy for implementing EA. Then the architecture effort has a
built-in business goal: create an architecture designed to deliver services to the business in terms it can understand. Simply put, it's the first technical concept I've seen in ten years that actually drives alignment between IT and the business.
We've been reasonably successful in conveying previously the value of EA to the enterprise... and using the description above, SOA. Much of the discussion at this point has be fairly abstract though, and this causes problems.
The article points out an interesting means to describe more of the "why" to the business. The portal returns. When I started in this business (as a web developer) web portals were just finishing their reign. Yahoo was dying off as the go-to place for the web, search engines were rising. Google was a novelty with it's nifty "I'm feeling lucky" feature. But the desire, at least in the library/information sector has always been to have a targeted vertical information portal specific to the needs of a particular group. What has been lacking is a reasonable and efficient means to enable the functionality of such a set of portals (e.g. offerings) until the relatively recent rise of SOA (and its parent EA).
The story that seems to be emerging across many
early adopters of SOA is that the SOA begins life as a portal. Someone
in IT or the business realizes that employees would be more effective
if they could avoid having to dig into two or more separate systems to
accomplish a task or a process. Or, it becomes clear that employees are
avoiding a system because they only need a tiny piece of the
functionality and the system requires that they understand much more
than they need to know. The portal--whether it's tailored to a
particular employee's work role or is simply a generic single interface
into many different systems, jump starts the process that is behind
SOA: abstraction of systems.
What is a service
really, besides being a higher-level abstraction of different
application and data sources in the IT infrastructure? A well-executed
portal is a marvel--undisputed ease-of-use combined with clear
productivity value. Everybody's happy.
Agreed. Tentatively.
EA and SOA are business things. We must finds ways to describe their value, and impact, to the business.
