US Assure

“Source once, consume many”. That has been my mantra for data management for years. The same goes for technical capabilities that enable the business. “Build once, consume many”.

Service oriented architecture, otherwise referred to as SOA, can mean many things to many people. You can ask an architect, and you may spend time discussing service bus layers, service catalogs and service contracts. Speak to someone in compliance, and you will end up discussing the governance of how services are accessed, audited and controlled. Talk to a developer and you will be discussing re-useable components or pieces of code that can be shared by applications. Talk to a six sigma black-belt and you will end up in a lean conversation on how to remove waste and standardize your processes to create efficiency.

So, how do you go about creating or making sense of service oriented architecture?

However you think about it, the concept centers around a “service”, i.e. a process or capability that is generic enough that can be used or consumed by multiple entities, in a way that reduces the need to build duplication or inefficiency into your organization.

These services may be built using different technology, code bases, and can be either real-time or batch. However built, there needs to be a method to your madness. They should be structured into a framework that is designed, so as to be able to expose, manage, and govern these services.

What I recommend is to logically map out the different needs of your business, which may be existing, or new, depending on your overall business strategy. This may require interviewing the different executive leaders across the organization as to what they see as the business priorities, goals, or future states.

Once you know the needs, you can they start to define the capabilities required to meet those needs. From here you have somewhat of a catalog of services needed to meet the needs of the organization, pointing towards a future state. There are many different frameworks you can leverage that will allow you to organize those services into a model that helps identify dependencies, and how services interface between systems, or key stake holders and partners. Some may end up calling this target architecture for services, in some regards.

At this stage you have a target state that can be assessed against the current state. You may already have current capabilities built out. The question is -are they built to support reuse and be consumed by various processes or systems? Map into the target state the items that exist that meet the SOA criteria and then identify the rebuild and gap items.

“A service that is designed to do a specific pure function scales up and down much easier than something that has multiple business logic components at once”

The next challenge is to figure out how to rebuild or build new SOA components with support from the business. Chances are you are not going to have a pile of budget dollars sitting around waiting for you to address this without a business case.

While there are many approaches to getting the technology infrastructure items addressed, two common approaches would be, one, to build a business case to address all at once head on. The other common approach is to use the current backlog of business requests to address items on a one by one approach. It’s the old, “while I have the hood of the car open, I will fix the issue as an incremental cost to the initiative”.

Regardless of the approach, it will take time to get across the bridge to a target state. Don’t forget that there will be the additional effort to migrate multiple consumers to the new services as you create them, and don’t forget about the decommissioning costs of the old services as well.

Don’t forget the governance. In larger organizations, especially ones with larger development groups, it’s important to define and declare who the owner/support team of the service is. If development groups don’t know about the new services, you are fighting a losing battle architecturally. Good governance will allow you to know who owns the service, who is consuming the service, and allow for auditing to confirm over time who continues to need access to the service and the data it provides access to.

At the end of the day, a SOA defined environment will provide much better transparency into your environment , a reduced number of new builds, less infrastructure to support and actually create some standardization that moves away from custom defined interfaces and services. In addition delivering smaller scope services support faster delivery cycles. A service that is deigned to do a specific pure function scales up and down much easier than something that has multiple business logic components at once.

Remember, the business will never sit still, so this will be an ongoing process that requires continual effort. Good luck on your journey.