How can Enterprise Architecture be used to improve service reuse in a Service Oriented Architecture? It is about finding the right granularity of the services, and lifting the focus from the primitive services towards processes and common information concepts.
Service orchestration
The services you identify, design and implement are dependent on the types of services you want, and how you structure them. Let us assume these layers:
- process orchestration – implementing business processes with both automated and manual steps.
- activity services – implementing fully automated processes within broader business processes. The activity services may use information from different information domains, like a payment process would use both services within the “customer” and “order” domain.
- information domain services – implementing operations on information entities, across the system portfolio, using integration services towards several systems and aggregating information.
- integration services – implementing operations on information entities towards a single system.
The service registry / repository established in a lot of IT organizations, enables reuse of already implemented services, but that alone tends to drive the actual reuse towards low-level services, like integration services towards specific systems, or quite specialized information aggregation services. The reason for this, is that process and process activity services in most cases are implemented based on a demand from an application development project, while the simpler services handling more basic information objects, implicitly match the needs for many projects to come. In order to get a higher potential for reuse of process / activity services, one needs to broaden the perspective to more application developments and, even more importantly, process improvements, at once.
The link between EA and SOA
EA is about planning ahead to reach a target architecture that captures the needs of the whole business, the needed capabilities of IT, and using that to scope and define the right projects, that iteratively will implement that target – through both business and IT initiatives.
SOA is about defining business-oriented functionality, which encapsulates what IT delivers to the business – as a whole. The most successful implementations of SOA is where you “think big, but implement small”, hence iterative implementation of the big picture.
The link between EA and SOA is obvious, especially when it comes the harmonization of needs across the business, and the holistic approach to IT.
The models within EA are the “tools” that enables the identification of the right services within a service oriented architecture. Examples of this are:
- a process map, and the process design of business critical processes, can be used to find the process and activity services that would create most value for the business, f.ex. by explicitly enabling most reuse
- conceptual and logical information models within the information architecture, should be the basis for a common object model in a SOA context, hence also information domain / information entity services.
- in order to find the right consumers of services, and the right providers of system interfaces, used by integrations services, functional application architecture and system architecture are two important enterprise-wide architectural perspectives.
By identifying which different types of information entities that flow through the business processes, and establishing a common ground for important information objects, you have a very good starting point for defining information services that could be reused in those processes. F.ex. if a customer, seen from a business perspective, is either a private or a corporate customer, and these two types of customers have little in common, the service composition should reflect that, hence a service simply called “CustomerService” would probably be inadequate and very difficult to make reusable.
EA is an enabler for reusable process activity services
An organization must be dedicated to enterprise architecture work if it wants to take advantage of the possible EA/SOA synergy effects. Both the business units and the IT departments should think of enterprise architecture as a way of defining the goals the business and IT want to achieve and, more specifically, which processes they want to improve.
- From the to-be process map, one needs to choose which value chains or which business processes from different value chains that are to be implemented. An insurance company may choose to improve the whole value chain for car insurance customers, or choose to improve the claim handling for all insurance types.
- Business processes that, from a conceptual perspective, have overlapping sub-process or process activity definitions should be identified, so that coherent processes could be improved together, either in a single project or through coordinated projects.
- Then these processes must be designed in more detail, from a business perspective, with the emphasis on how they want things to work, not the limitations of today.
- These processes must then be analyzed together, in what I call a process / activity matrix
- similar activities in different processes can now be identified, and these represent potentially common activities, hence reusable activity services. For a public organization managing a lot of different applications (building permits, kindergarten applications etc.), there are some decisions that could be automated, while others need to stay manual. The activity automation candidates here would imply good candidates for service reuse as well.
- some activities in the different processes may be doing some common “sub-activities”, but differ too much to constitute a potential reuse – in this case the activities should be modularized or consolidated, in order to find the common activities, hence the reusable services with the most adequate granularity. Within a manual decision process, the activities that publish or send the decisions may still be automated, hence reused from the automated decision activity.
Using tools to further enhance reuse potential
It is impossible to discuss such potentially complex intellectual tasks without mentioning tooling. If all business processes, their sub-processes, their automatic and manual activities, are modeled and designed in the same tool, and it is all well structured in a common repository, the steps mentioned above will become much smoother.
Consider this scenario: A business analyst in a bank models the loan application process, in which he defines an activity called “evaluate customer”. That activity is later linked to a service that implements this evaluation, which implies a relation to a credit check service as well. Somewhere else in the same bank, another business analyst models the customer registration process, where the need for screening the customers becomes apparent. Then he sees the “evaluate customer” activity in the repository of business processes, so he decides to put that activity in his own process. Then he has implicitly created a relation between his process and a couple of existing or planned activity services, which means that those services are going to be reused.
Enterprise architecture – planning – improvements – services
So, back to where we started: enabling service reuse through enterprise-wide architecture activities – can you achieve this in practice?
As I’ve already mentioned, it requires dedication from both business representatives and IT architects, and clear mandates to those who are in between: enterprise architects. If EA is used as the basis for project portfolio management, and the organization is serious about business process management and service oriented architecture, taking advantage of the link between EA and SOA is just the natural step for harvesting the actual benefits of being service oriented.
