English | EN 
Part 1
What 15 years ago was launched as Service Oriented Architecture, SOA, contained many promises for support to develop an agile business (see the chapter Rethink Your Business in the book SOA for profit). I didn’t take long until the term was hijacked by an army of technologists and their companies claiming that they sell SOA products and components. I remember when I got an invitation to speak at an SOA conference. When I looked at the conference programme I could read the first row, “SOA is a technology..”. I immediately answered “no thanks”. How can an architecture be a technology? Next phase in the SOA life was a dark period where many claimed that “SOA is dead”. How can an architecture be dead? Many clever architects continued to work with SOA as the only architectural concept that could meet the arising ever-changing reality for many companies, this without mentioning the term SOA. Suddenly something happened again. Microservices became a kind of object-oriented approach to building solutions. Still very technical. A new type of products was released, API gateways. The technologists claimed that the ESB is dead, “long live the API gateway..”. I remember a discussion with a young architect that could spend hours to explain the difference between Enterprise Service Bus and API gateways. As an Enterprise Architect, I didn’t see any difference. Two different type of products that both can act as the foundation for a Service Oriented Architecture.
Lately, I have heard several companies talking about services in many different situations. Services approach is still how many large industries try to expand and sharpen their business. Different IT domains like Business Intelligence are now talking more about services as a way to structure what is provided to the business. In a way, we are back where we started but in an even more demanding environment.
I have worked with a couple organizations around business intelligence and regarding architecture the last years. I have tried to define the conceptual architecture as services, business services or packaged solutions formulated in business terms. I have found it hard to get the organizations to define the services, but suddenly I got a break-through. In a public agency I worked with they found it easy to define business services for the Business Intelligence & Analytics department.
Services can according to my research be sorted into the following:
The type of Services may be divided differently, but the ones in the boxes above are a good starting point and platform. A short description.
Solution Services are services that provide a technical solution.
Base Services came up in our project because of the need for self-service. It is more about providing infrastructure, platform, and tools. An example of Base Service in the area of Business Intelligence is Access to one or more data sources, a tool to refine the semantics of the data content, and a toolkit to be used for self-service.
The most important type of Solution services is Business Services, though. A Business Service is a pre-defined functional solution that supports a clear business demand. More about Business Services in Part 2 of this blog post.
Assignment Services are standardized services that can be ordered from the service center and that is not resulting in an implemented solution. In other terms, it can be services like pre-study, Innovation WS, PoC, data-analysis, etc. The more clear, the better. An assignment service should have a clear objective, a methodology and a template for the result.
Support Services are service related to operations and application management. Common examples in IT operations are Helpdesk, Support to different stakeholders, Incident Management, Problem Management, Bug fixing, and more…
Device Services is a kind of service type that is not obvious to everyone. It came to my mind when an IT strategist in a healthcare county talked about a service the provided; Mobile phone administration. The managed ordering and delivery of standardized phones with SIM card. This more hardware-oriented service can be applied to many cases in the coming era of IoT. The service differs quite a lot from an Application Management, and they should be kept apart.
The important objective for all type of services is to achieve standardization from different viewpoints to a valuable level.
Many people think of standardization as something boring, old school and the opposite to agile.
As a matter of fact, the standardization through services is the opposite.
It is all about standardizing components to an optimized level between shorter time to market and business agility.
To think services is very useful in many cases. I talk about architecture in this blog post. Another area I have applied it on is Digital Transformation. It is not possible to make a good Digital Strategy without focusing on services.
To be continued..
