A couple of weeks ago during a business meeting we got asked our recommendations on how an enterprise can set up Service Oriented Architecture (SOA) Governance. Before we continue and share our ideas on the subject we need to define some important terms.
What is SOA?
Wikipedia defines Service Oriented Architecture (SOA) as a software design that builds discrete pieces of software that provide application functionality as a service to other applications. At its core SOA is a software design principle that makes functionality available to other applications for use. For example, if you were building a sales management application using a SOA software design, you would probably build a create order software service. That is, you would develop a discrete piece of software within your order taking application to allow other applications to create orders.
SOA allows different applications, which can be developed in different languages, to interact with each other across network communication. By concentrating the offered service into a single access point, there is only one software to maintain. That is, using our previous create order software service example, if we added one additional validation to that software service every application that used the create order software service would be updated with the new validation.
The main goal of SOA is to promote business through interconnected services. By having SOA services available at an enterprise, new applications are developed faster and are less prone to error as they only have to consume available services versus having to recode functionality again. That is, we would consume the create order software service, instead of having to code a new create order functionality.
What is Governance?
The term Governance can have a lot of meanings. According to Wikipedia, Governance is “the act of governing. It relates to decisions that define expectations, grant power, or verify performance. In the case of a business or of a non-profit organization, governance relates to consistent management, cohesive policies, guidance, processes and decision-rights for a given area of responsibility”. Basically for business, Governance is a set of processes and best practices that assure consistent optimal operational results.
For the purpose of our conversation Governance is more than establishing a framework for SOA monitoring, auditing, and management. SOA Governance is the process by which organizations handle access to their underlying data and processes through the reuse of their current application infrastructure. It is a layer on top of the Enterprise Data layer.
What can we learn from the Data Layer?
Most, if not all, enterprise organizations understand the need for Enterprise Data Governance. That is, the processes by which they control, monitor, manage, and audit their business data. Most organizations have some type of Enterprise Data Governance process in place and understand the value of a single point of truth for the organization. That is, that the data should only exist in one place in the Organization not in multiple locations. For example, having one database that holds the sales data, not multiple data stores across the organizations.
The benefits of a single point of truth are self-evident and outside the scope of our conversation. But it does not take a PhD to figure out that if, for example, the sales data is stored in multiple locations at some point all locations will not have the same data. Can you imagine going into a meeting and having the Marketing Department report sales numbers that are completely different than the ones the Sales Department reported, which in turn are different from what the Finance Department has in the books. When this happens, and trust me it will happen, which data store holds the true sales data?
In order to deal with this problem organizations have opted to use a single data store approach to storing data. Using this approach they can monitor the use and quality of the data, while centrally controlling access to it. In the end organizations that use this approach achieve a single version of the truth for its data.
How SOA and your Data Layer are alike
Now, something similar can happen when applications are pushing data into your single data stores. Using our same sales data example, what happens if you have multiple applications inserting sales into the data store? What happens if these applications are not using the same business rules to add sales into the data store? Can one of the applications be adding incorrect sales into the data store? Sure it can. But do not worry, you can control this by using a SOA Governance process.
What is SOA Governance?
SOA Governance is the process by which you assure the proper management, handling, and processing of your SOA services while mitigating any potential business risks and identifying new SOA service opportunities. SOA Governance must include:
- Process Register
- Risk Register
- SOA Service
- Monitoring Capabilities
- Centralized Security Management
- Quality Assurance
- Auditing Capabilities
- Continuous Improvement
Process Register
SOA governance must commence with the creation of a Process Register Document (PRD). This document will record all important software processes in the organization. The PRD must at its minimum include a list of all identical processes that are executed in multiple applications and processes that create data for the organization.
Identical processes that are executed in multiple applications are identical functionalities that can be performed in different applications. For example, if you could retrieve the status of a service order from the Company Web Portal, Customer Relationship Management (CRM) Application, or Service Management Application, then the retrieve service order status process would be a process that is executed in multiple locations and as such would be included in the PRD.
Processes that create data for the organization are for example, processes that create new orders or service request. Basically, these are processes that create the business data for the organization.
The PRD must contain the following information:
- Process name
- Description
- Level of importance to the organization
- Where does the created data is stored
- Which applications use the data
- Process owner
- List of Applications that create this type of data
- Application name
- Application technology
- How the data is inserted
- Business rules applied for the creation, storing, or reading of the data
- Application owner
The PRD will give us a magnitude of scope for our SOA Governance initiative and provide us a master document of our SOA services and consumers, the applications that are using our SOA services. The goal of the PRD is to identify all the processes where the organization should implement a SOA strategy.
Risk Register
Once we have our PRD, as with all Governance processes, we need to create a Risk Register Document (RRD) to properly document our business risks and how we are going to mitigate these. The RRD must at least contain:
- Risk name
- Description
- Importance
- Risk score
- Likelihood
- Impact
- Process affected by the risk
- If the risk needs mitigation then we need to document how it will be mitigated
- Risk owner
It is important to emphasize the need to continually update the PRD and RRD. Governance is not a one-time process it is a continuous activity. True Governance does not exist if the process is not continually improved. It is an iterative activity that is continually happening and improving in the organization.
SOA Service
Now that we have documented all our processes and risks we need to develop our SOA services using a best in class approach. That is, we need to make sure our SOA services can be:
- Secured
- Monitored
- Audited
- Quality Tested
We have always followed an approach were an initial golden reference implementation is developed and that is then used as the foundation for all other services. This way you guarantee a best in class approach and build the foundation for a standard approach across the organization.
SOA Dashboard (Monitoring, Auditing, and Security Capabilities)
The organization needs to have a SOA Dashboard, a centralized location where all SOA services can be viewed, monitored, audited, secured and quality assured. The SOA Dashboard will allow an administrator to view all SOA Services that are available in the organization.
Administrators should also be able to see which SOA services are currently in use and by whom. It will also allow administrators visibility into the processes overall use, effectiveness and security settings. Administrators must be able to centrally change the security settings for all SOA services within the organization. Finally the SOA Dashboard must allow for the viewing of audit logs in order for quality test to be performed.
All SOA services must communicate with the SOA Dashboard. This will allow for centralized monitoring and auditing of al SOA services in the enterprise.
Quality Assurance
All SOA services must be continually verified to assure their quality. Quality Assurance is another continuous process that must be periodically performed. Quality Assurance can be automated through a set of programmed automatic tests or can be a manual process in which someone performs a quality test on the service.
Quality Assurance can be even built into the SOA service by having an independent process validate the quality of the performed service. For example, if you had a create order service there could be a final routine in the service that validates that the information provided to the service to create the order is exactly the data that was inserted into the data store.
The value of Quality Assurance is not on the method used to validate quality, but on the continual execution of quality verification.
Great I have SOA Governance, but will this work?
In order to accomplish SOA Governance an organization needs to secure its data and processes. If a SOA services exists for a given functionality then no other application should exist that has direct access to its underlying data or should be allowed to reproduce its functionality. That is, if you have a SOA service to create an order, then no other application in the organization should be allowed to create an order unless it is using the create order SOA service. Likewise, no other application should be allowed to insert data directly into the order data store.
One way of securing the organizations processes and data is to create a SOA Administrator position. The SOA Administrator would be charged with identifying and securing all SOA processes. The SOA Administrator would work directly with the Database Administrator to make sure all data is secure and access to certain data is only permitted by the use of a SOA service. In a large enterprise there might be several SOA Administrators or even a SOA Department, to handle a large volume of SOA services.
By Implementing SOA Governance in your organization you will assure data integrity across the enterprise and develop a foundation of services that will allow new business applications to be developed faster and with improved quality.
Would like us to share more information on a particular area of SOA Governance or need a SOA Governance assessment? Please let us know.
