[Interview] Establishing an SOA-Focused Enterprise Architecture

What is Service Oriented Architecture (SOA) and for how long has it been around?

SOA is traditionally defined as a highly loosely-coupled distribution system, but my take is that it’s nothing new; it’s an architecture style rather than a pattern that can be used to fix broken architectures.

In earlier times, what were the components of SOA?

SOA had three main components; the service provider who provides the service, the service broker who allows you to look up the services, and the service consumer who navigates the services from the broker and consumes the service from the service provider.

Why has it progressed with time and how has it changed?

It had to grow to be able to meet business and technical requirements. Initially, it only needed to cater to desktop applications, but later, different types of service consumers came into the picture as well.

In the second level, users identified and distinguished between fine grain services and course grain services; they also differentiated the business process from the service layer.

Could you explain the design time involved in the current SOA?

There are many prerequisites to build enterprise architecture; therefore, a lot of technical components are needed to meet these requirements. Service layers, a mediation layer, certain business processes, and API management are all key components required to address business challenges.

What about runtime?

Runtime is more complex because you need to have multiple deployment layers that need to be both deployed and managed.

Would you agree that API management is the missing link for SOA success?

I agree, and I echo Sanjiva’s (Sanjiva Weerawarana - Founder and CEO of WSO2) thoughts that most enterprise architects are struggling with services because they are built on silos. The whole concept of SOA is to have shared, reusable services. An API can be seen as a solution because it can encapsulate different types of service layers and provide a single interface to the consumer.

How is this single interface format easier to use and how is this implemented?

The interfaces or APIs published in a Store (API Store) - developers can easily look at and navigate through the APIs, subscribe to APIs, and consume them all in one place.

It is solved through the API façade pattern. Most of the services are not API ready, so a mediation layer is implemented between the back-end services and the APIs, making it a façade.

Why did enterprises have to come up with the concept of enterprise architecture?

It links with what I said earlier about how services are built in silos. Each group in a business will have a different set of architects who develop and use different standards. This became an issue, especially with regard to return on investment (ROI), because even though businesses spent a lot of money, tasks were constantly being duplicated.

Was enterprise architecture the first solution enterprises came up with?

No. Initially there were architecture steering committees and review groups to oversee the different business groups. It was much later that the enterprise architecture concept came into place to manage and govern the services while ensuring greater ROI.

Could you explain some challenges faced by enterprise architects?

Firstly, there is less visibility and enterprise architects don’t know what’s actually happening in each project. It is also difficult to figure out who the owners of certain services are. The service may be running, but they don’t know who’s managing it.

Another issue is that the development lifecycle is cut down to smaller sections because people give the architects requirements and expect quick results. Standardization is done in two ways - technical (REST, SOAP) and business (ACCORD, HL7); integration is a key challenge because the heterogeneous nature of the systems calls for a requirement to build connectors to communicate efficiently.

What are the basic steps taken when building a reference architecture?

First you need to get the requirements and identify the business patterns. Thereafter, the applications and runtime patterns are figured out and finally product mapping takes place.

How do business architects contribute towards figuring out the business patterns?

Along with enterprise architecture came a new concept called business architecture. Business analysts write 100-200 page documents on the business requirements; however, these documents are never used or are not useful in projects. What business architects do is take the analyst’s document and identify the technical requirements. They document the requirements in a way that makes it easy for the technical teams to deliver results.

What do you mean by application patterns and runtime patterns and why are they important?

Application patterns involve figuring out what sort of a system are needed to be built and the applications that have to be included. The runtime patterns involve when and where it is deployed and how it looks during runtime. This is crucial because it helps to understand how to apply proper security architecture and identify how to scale and have high availability.

Can you explain the final step - product mapping?

One approach to this is to get a completely new system and replace its contents, but what we always recommend is to leverage the existing system, applications, databases, etc. You will need to look at what you already have and what you need to bring in to bridge the gaps.

What about integration?

The integration patterns will be implemented with each and every step so all the other components will be connected by using the integration pattern.

What happens after the reference architecture is built?

We follow a model called Level 0 (L0) Architecture. The requirements are identified by looking at the components rather than looking at specific products or vendors. It can be seen as a vendor neutral architecture diagram.

When do products or vendors get involved in the architecture?

The L0 architecture needs to be transformed into L1 architecture. This is where the products needed for implementation are included.

What is the business service platform?

The component architecture contains the current IT infrastructure of a particular organization. Thereafter, the future IT strategies and the external and internal service consumers need to be identified. These pieces are connected through the business service platform.

Can you elaborate on the components of the BSP?

If you look into the BSP you can identify different layers. The first layer is the integration layer. Then the web-oriented architecture (WOA) is required to provide the business capabilities to access and build both web and mobile apps. There are also different types of business processes; some that already exist and others that have to be newly developed. Service hosting is required for writing services and putting them into runtime in order to enable access to them.

The unified data model is a key part of the BSP because it allows you to keep data in its format even if the different data sources represent the same entity in different ways. This is what allows you to change the system because the internal parts follow a standard data model. There also should be a data access layer because you would have to deal with a lot of data repositories. Finally, there’s governance and security, which ensure quality of services.

How would you describe the BSP layered architecture?

It contains two integration layers with the internal data model in between them. The bottom layer is required to communicate with the external and internal systems. The service platform represents the current available services, and new business services can be introduced as well. Below that there will be another data model that deals with the data sources and finally the data access layer communicates with the different data sources.

What are the first steps of implementing the BSP?

The first step in architecture like this is to implement the internal integration. You can use WSO2 Data Services Server and WSO2 Enterprise Service Bus to connect the current services and data to create the internal integration layer.

Where do you go from there?

You then introduce the new services. You can get a lot of functionality from the existing services as well as the existing system. You have to identify, write, and deploy the new services inside the service container. This can be done using WSO2 Application Server. Thereafter, you use governance to introduce policies to manage your architecture. To further improve this, you need to implement security. This can be done by plugging a security model to an internal LDAP (lightweight directory access protocol) or an activity directory.

So at this point you would have an end-to-end working system secured and governed. Is there any way to add more value to the architecture?

Yes, by introducing monitoring. By using WSO2 Business Activity Monitor you can expose the internal services as APIs and introduce mobile. It will bring the API store into the picture and enable you to have more portals.

So there are two levels of registry now because of the API store/registry and the governance registry?

That’s correct. This is something that confuses many architects - there is both service governance and API governance. Service governance has become an internal DevOps portal because it will only use the service registry to manage the services. But whoever consumes the service will come through the API management layer, hence they will use the API store as the registry to find the services.

What would you say are the differences between the traditional service registry and the API store/registry?

The traditional service registry provides only technical information that may not be useful to the service consumer. The difference with the API store is that it provides a lot of information in a social way so that the developers can easily identify the patterns and capabilities provided by the API without going through any documentation.

Why is a configuration-driven model more useful than a code-driven one?

It is a fact that professional coders make approximately 100 to 150 errors per thousand lines of code. So, the code needs to be tested and debugged. The configuration model is very useful because code can quickly be configured and put into production without any issues. The go-to market will be very high if you have a configuration-driven approach, but the correct toolset needs to be selected to sustain its efficiency.

How do configuration-driven systems work in WSO2 products?

Most WSO2 products have a declarative language. Currently, it is more XML savvy, but we hope to support JSON-based configurations in the near future. We also have a lot of graphical editors that can be used to configure the code.

Can you describe some advantages of using SOA in enterprise architecture?

SOA helps enterprise architects overcome the challenges of enterprise architecture. It provides loosely coupled services that allow quick releases to be made. This also means that changes can be made to the system because it is easy to rewire them. That means there is a lot of flexibility to carry out architecture changes without affecting the production system. The go-to market will also be very high and the heterogeneous environment allows the user to fix the best tool for their specific needs. Governance gives the user a clear picture of the current status and will help them manage dependencies and identify when a change has occurred as well as its resultant impact.