Introduction
A couple of years ago, I consulted for the power grid operator in Norway called Hafslund Nett, now called Elvia. I saw that here, as in many other companies I have consulted, developers used the terms application, system, and service more or less interchangeably. It was leading to a lot of confusion. I decided to create a Service Oriented Architecture Framework (super “enterprisy, I know) to have a more ubiquitous language. The framework is not some library, and I am well aware of the potential pitfalls of creating some overarching, all-encompassing framework that is simply annoying to everyone.
We need to get some prerequisites out of the way before moving to the “framework.” First off, viewpoints.
Viewpoint
I have been doing consulting work for the Airport Express Train as a solution architect. The business stakeholders heavily used the word ticket, but as you can imagine, it had different semantics depending on who you addressed. For one department, it meant the receipt showing that you had paid; for another, it was the token that gave the traveler access to the train. It was interesting to be in meetings where these different parties would discuss without being clear about the context they brought to the table. Both parties had both different but correct definitions.
Confusing between syntax and semantics is, of course, not a new observation as it is more or less the basis of the vital concept of Ubiquitous Language in Domain-Driven Design. The syntax of a word can be the same. However, its semantics can be completely different depending on the context. Why am I talking about this? Whenever I have presented and discussed the framework, inedible the discussions come up where people are correct about their definition of a word I am using but completely forget that we are talking about a narrow bounded context of service-oriented architecture.
System - the forgotten word?
Let us look at one last prerequisite. It seems to me that we tend to forget the word system when discussing architecture. Instead, we developers tend to overuse the word service. When I started Computer Science at university, I was on a line called System development and data communication. The line is now called programming and modeling. In Norwegian, we are also talking about systemutvikling - systems development. Programming is essential, as is modeling, but let us not forget about the system design.
The framework
The “framework” is heavily influenced by the brilliant course Advanced Distributed System Design by Udi Dahan and the C4 model by Simon Brown. The framework is not one of those super opinionated that killed SOA in the first place. Maybe the new SOA definition could be - Microservices done correctly?
The goal of the framework is to provide a particular viewpoint and what the following words mean in that viewpoint:
- Technology
- Application
- System
- Service
The framework also suggests what the different organizational roles should be mostly focused on. Take that as you may. Remember, the viewpoint for the framework is Service Oriented Architecture. If you talk to a frontend developer, the word service can mean something completely different. That is, of course, completely fine. Do not try to merge the two worlds, though. I have had other architects at clients attempting to incorporate different perspectives into the framework, especially from the business side. It does not work and leads to confusion. Instead, create something new and clarify how the viewpoint differs from service-oriented architecture.
Technology
Technology is the lowest layer. It consists of programming, languages, and frameworks. The developers are primarily concerned with choosing the correct subset of all the available technology and building applications. They are, of course, not limited to that, but they are the main drivers in that regard.
Applications
I am using the exact definition of Simon Brown in his C4 framework. An application is a deployable unit that can be deployed on its own. Examples are a web application server running in a Kubernetes (K8s) container. The critical distinction here is that once an application starts to “talk” to another application, we are automatically talking about a system.
System
The diagram shows that applications A and B constitute system X. Now we are automatically entering all of the messy fallacies of distributed computing. Can we deploy a new version of application A without deploying a new version of B simultaneously? What happens if there is a bug in the network so application A can not talk to Application B?
Each system has at least one dedicated tech lead. The tech lead’s main job is to ensure that we are creating the correct applications and how they collaborate to provide the proper system functionality. The tech lead should also be working with the system’s reliability, alarms, escalation policies in case of incidents, etc. A good tech lead will create a good environment where it is easy for the developers to concentrate on making suitable applications and systems. The developers will also be working with the tech lead on system design, but the tech lead works more closely with the organization’s architects on the service layer.
Service
This layer is the missing binding layer between the IT and business of an organization. The service layer is also the one I have had most discussions about when presenting the framework to new organizations. The service layer is where the architects spend most of their time.
Let’s imagine that the board of a power grid operator desires, based on data, that they need to provide a new service to their customers: solar panel installation and data insights. The board talks to the enterprise architect and instructs her to start the necessary steps to implement it.
A service is an alias over a subset of the different endpoints available from N number of systems. The alias does not change but creates an abstraction that the board and end customers can discuss and use for reference. Let’s look at an example pretending we are Google. One service that Google has is called Gmail. On closer inspection, it probably consists of multiple systems under the hood. Maybe they have something like: a spam classifier, chat, email search, and email editor. For the end-user, it is entirely irrelevant. Notice that the chat system could be down, but if the systems are created correctly, the email functionality should still be up and running.
The service layer is the missing layer between the business and technology parts of an organization.
Example of using the framework in a cloud environment
On the left-hand side of the diagram, you will see examples of technology that can deploy the different layers. The applications are K8s deployments, stateful sets, or potentially (cron) jobs. I have usually encapsulated systems into K8s namespaces, and there is a one-to-one relationship between a system, team, and K8s namespace. For services, you could expose them through an API Management solution, for example Azure API Management.
Tips on introducing the framework
To increase the chance of implementing the framework it could be a good idea to do a friendly reminder whenever people are a bit unclear about application and system for example. In addition try to move the conversation more towards system instead of the overused term service.
Also, keep reminding that this framwork is not meant to replace all discussions in all teams. This is solely meant to help when creating new systems, provide new services to customers and internal discussions in teams on what applications to create.
Policy
In my experience the framework kicks of some interesting discussions about cross team communication. Should applications in one system be able to directly call applications in another system if they are in the same K8s cluster for example, or should they use the service path like external consumers? No right answer, but now at least we have a clear definition of the terms and can hopefully have a more precise discussion.
Conclusion
The SOA Framework has provided value whenever I have used it with customers. One of the reasons I think is that it does not put any constraints on how the applications are written, it is solely working on a much higher level of abstraction helping to clear up some terms, give an overview of the teams, their systems and how to expose the services.