In my last post I have covered the basics of EAM. We also have established that you need and EA or EAM for BPM. BPM comes in two forms: Business BPM and Technical BPM. Business BPM uses business lingo to describe business architecture – activities, processes, organizations, products and all sorts of resources etc. Technical BPM describes the execution of business processes; usually what we understand as workflow or SOA.
SOA stands for Service Oriented Architecture or you could say Architecture Oriented towards Services. That does not roll off the tongue very well but is the core of the message. We are building an architecture here - not just a bunch of web services that may or may not support your business (process). Unfortunately this gets lost in translation somehow to often. What are the components of the service architecture? This is where it gets philosophical but I would say that SOA is primarily a cross section of the business architecture and the application architecture.
The business architecture describes the activities and processes that consume services in order to perform or provide services by themselves. Since services provide capabilities required by the business we need to identify the requirement first in order to know what services we need. In addition to that the business architecture provides information about process components and activities and where they are used. One of the principles of SOA is reusability. Therefore we need to identify repeatedly used processes and often required capabilities in order to identify candidates for a service.
The application architecture describes the technical side of the SOA in form of applications, software services, IT components, etc needed to support an implementation. In addition to that we need of course also parts of the information architecture and technology architecture. Software services are platform independent descriptions of a service implemented as software – duh. The implementation specific information also called web services is described in form of the actual applications represented as WSDL.
We glue all of this together using business services – a computer independent description of the services. A business service is characterized by capabilities it provides, data inputs and outputs, supported business objectives, measurements, service level agreements and a whole lot more. The business services are linked to the consuming and providing processes where applicable. Note that you can have a perfectly defined SOA without a single web service or software service. Services can be provided by processes or organizations and don’t have to be software.
Now we have an architecture and that means we need architecture management. The standards, conventions, semantics and managing processes are governed by the EAM. But we also need SOA specific governance. That is described in service management processes and procedures. The procedures describe who to manage service information in general e.g. standards to use, technology components etc. The processes describe how an individual service is handled through its lifecycle from conception to implementation to retirement.
Read more about SOA: www.aris.com/soa
