In this article, we will discuss Service Architecture, what is it, and how does it help (your organisation with its business transformation).
If you want to transform your business or help your clients transform theirs and want to do it quicker, with less resistance, then this is for you.
Full disclosure – in this context, we are talking about Business-Services (referred to as simply ‘Services’ from this point). These are services that the Business (with capital B) develop, promote, and sell to customers (as opposed to technical or technology-services, also often known or referred to as ‘micro-services’).
There is much talk and confusion about services, service models, service architecture and service catalogues and its comparison or alignment to business architecture? In this post, we will set the record straight for once and for all, so you focus on the things that matter, not hype and distraction the marketing, sales or legal department want you to focus on.
Services are becoming an increasingly important part of organizations today, as they often thought of as a way to organise, modernize and streamline operations. Service models, service architecture, and service catalogues are terms that are often used interchangeably when discussing services. To understand how these pieces fit together, it is important to understand the differences between each of them.
In this post, we will cover:
- What is Service Architecture,
- What is Service Model,
- What is Service Catalogue,
- Problems with implementing it, and
- Comparison and where does it fit in with Business Architecture (or not).
What is Service Architecture?
Service architecture provides a framework and process for designing, building, and managing services in an organization. This process helps to ensure that all parts of a service system operate as expected and have an agile approach to responding to changes in the market. It is typically used to guide the development of new services or changes in existing services.
Business architecture, on the other hand, provides a framework for creating an effective business environment by looking at the entire enterprise from a holistic perspective. It involves understanding how different areas of the organization interact and function together to achieve success. Business architecture typically focuses on strategy alignment, customer experience optimization, process improvement, resource utilization, efficiency gains, and more.
Then there’s Technology Architecture. Technology architecture is concerned with enabling the organization to make use of technology solutions in a cost-effective manner. Technology architecture focuses on selecting the appropriate technology components and systems that will best meet an organization’s business requirements. This includes understanding how enterprise-wide solutions integrate, as well as how applications, services, and infrastructure connect. Technology architecture also ensures that the chosen solutions are reliable and secure.
When these last two core architectures are taken together, business architecture and technology architecture form an integrated framework for driving the implementation of effective organizational strategies. By defining how business components interact with technological solutions, organizations can ensure that their investments in technology will align closely with their overall business objectives.
If you didn’t already know – what this leads to, is better decision-making, improved operational efficiency and effectiveness, and ultimately, greater success.
A well-designed enterprise architecture (i.e., business & technology) helps organizations save time and money by optimizing the use of their resources. With a clear set of standards, best practices, and processes in place, teams can streamline their workflows, more effective collaboration between business stakeholders, IT teams, and other key personnel, and quickly identify areas where they need to improve efficiency and reduce waste.
What is a Service Model?
A service model describes the methodology, processes, and tools that are used to provide business-services (“services”) to its customers. It defines a set of processes which can be reused to develop and deploy services within and across an organization. This ‘model’ is often referred to a ‘service-delivery’ model, popularised by IS Operations, or commonly referred to as IS Support. This is the team and/or department in the Organisation that handles IS or IT Incident management. These guys are often referred to as ‘IT Support’.
Their ‘service-delivery’ model is typically the 3-teir or 3-lines-of-defence (LoD) model:
Level 1 – minor issues or quick fixes (handed by a self-service or self-directed portal)
Level 2 – simple issues (handed by a person, either junior or midlevel engineer at the end of the phone, email and/or chatbot), and
Level 3 – complex issues (also handed by a person, but more senior with more experience who can deal with complex issues).
What is a Service Catalogue
A service catalogue is exactly that. A catalogue or register of the services. A well written service catalogue will have at a minimum – the name, description, processes that enable it, and Service Owner, who is responsible for its successful running.
The benefits of implementing a ‘service architecture’ is organizations can unlock tremendous benefits from their services. But theres a catch.
Benefits of Implementing a Service Architecture
The benefits of implementing a ‘service architecture’ is organizations can unlock tremendous benefits from their services. They can reduce complexity, improve reliability and security, foster innovation, and create an agile environment that is more responsive to customer demands.
So, if Service Architecture is so great, then what’s the catch?
The Problem with Implementing Service Architecture
The catch is this. Implementation.
There is a lot of confusion around Service Architecture, where it sits in an organisations overall Enterprise Architecture, and specifically with its Business Architecture.
So here it is.
The Comparison of Service Architecture with Business Architecture
Where does Service Architecture fit within Enterprise Architecture? Technically (pardon the pun), it doesn’t (shock horror!). Let me explain.
Services, like Products are not part of Enterprise Architecture, they are outputs of it. Don’t just believe me, I didn’t invent it, TOGAF clearly defined Enterprise Architecture, which has the two (2) main domains – Business, and Information Technology (IT), with IT having the sub-domains Information System Architecture, and Technology Architecture, as shown below:
So, if Services (and by association Service Architecture) are not part or Enterprise Architecture, where does it sit?
Good question.
Services are a means, method, or channel (however you want to describe it) to access the organisations Business Capabilities, as shown in the diagram below:
All ‘services’ are doing, is accessing the ‘business capabilities’ that enable the business to deliver those services, and as we know, where is the work done to deliver these services – in the processes.
Looking at the model above, you can see that the Enterprise Architecture is made up of those two (2) parts mentioned earlier – the Business Architecture (mostly people, and process), which is enabled by and supported by the IT Architecture, which is just how it is in reality.
Conclusion:
So why is there confusion with ‘services?
There is usually confusion with Services for several reasons, and when trying to solve any problem, you know how we do it here at HOBA Tech, and with HOBA, is getting to the root cause and start addressing the problem from there.
The first problem is why I created and made HOBA public in the first place after 10-years in use with private clients, is to give the Business their voice back, from the technology dominated ‘business-transformation’ sector.
If you plan on implementing a ‘service model’, ‘service architecture’, or ‘service catalogue’ approach to your Organisation, programme or project, the problem is the starting point.
Currently in the marketplace, the starting point is a ‘service model, service architecture, or where it is all documented, in a ‘service catalogue’.
The problem with this is, often that ‘service catalogue’ is written independent of the Business, in most cases, a marketing or a legal document, that is been divided up into parts or sections, and named ‘services. The project or programme tasked with implementing it will then allocate those ‘services’ (sections of a legal document) to the Business, that is ‘Business’ identified by ‘functions’ e.g., Marketing, Finance, Operations etc, and told ‘there you go, these are for you’.
That’s the first problem. The problem with that is the starting point.
Currently in the marketplace, the starting point is a ‘service model, service architecture, or where it is all documented, in a ‘service catalogue’. Thats the first problem.
The Solution
The starting point in implementing any service architecture, service model and service catalogue for that matter, is always the same. First need to understand what the Business does today.
What does that mean, and how do you do that exactly? To understand the ‘current state’, what that means in practice and Business Architecture, is you understand the core components of the Business Architecture, and how you do that is you model and map them.
Specifically, you model and map the core business architecture building blocks:
– The Organisation Structure (i.e., Organisation Mapping) – this is going to tell you who’s in scope (and who’s not i.e., who’s doing the work)
– The Stakeholders (via Stakeholder Mapping) – this is going to tell you what the people i.e., teams and stakeholders within the ins-cope Org structure are doing (e.g., their roles and responsibilities – the clue here is: in these descriptions, they should be saying or tell you what services they are doing now. They might not call them ‘services’, because you are just implementing it now, but the activities will be the same)
– The User Journey (via User Journey Mapping) – this is going to tell you what that Customer Journey looks like, who is the Customer, the channels they use to interact with the organisation, the good points, pain points, and improvement opportunities, and most importantly…
– The Process Model and Processes (via Process Mapping) – this is going to tell you all the processes in scope (via the Process Model). Note – the process model is exactly that – it’s a model, in HOBA it’s the 4-level end-to-end process model that covers the totality of all processes in-scope for the in-scope division or team from the Org Mapping above. Reminder – as discussed on previous posts, this part of business transformation projects scares the hell out of stakeholders, namely the C-suite, when you say, “we need to understand the organisation today’. Entire cottage industries can be and have been created around process modelling and mapping. There is however a simple way to avoid this, and that is a two-step approach – first you model all the in-scope process via the 4-level process model – so you have all the known processes on a single process model, then for all of the problem, troublesome or most painful processes, you actually create (or recreate) the level 4 (the lowest level of process mapping) process map. What you will find, is of the total in-scope processes, you will probably only have 4-5 painful processes out of 80-90 processes that need ‘mapping’ to gain consensus on what is the actual process, or what actually happens in that process. You do not need to ‘map’ all the processes, not when you have quickly tried to establish a ‘baseline’ of the organisation, and what it does today. Next is the all-important.
– Business Capabilities (via Business Capability Mapping) – this is going to tell you what Business Capabilities those processes are enabling. Note – this is the big aha moment for some! Business Capabilities are magical or mythical unicorns that appear out of nowhere or just appear or happen by themselves. If Business Capabilities are not mapped to a process(es), with people, inputs, process (steps), outputs and customers (aka SIPOC), you don’t have a Business Capability, you have a ‘wish list’. Business Capabilities that aren’t mapped nor enabled by a business process(es) is what we call in Business Architecture – ‘Marketecture”. Interesting, but meaningless. When you try to implement that ‘Business capability” or walk around the building to see it in action, you should expect to see a person or system performing it. If you do, you should be able to put a name on it (the name of the process or activity they are doing). If you can’t, then you either remove it from your Business Capability Model or mark it as ‘proposed’ on your capability model as it doesn’t exist.
Now, once you have mapped and modelled the ‘current state’, you then look to see which business capabilities, supported by their enabling business processes are delivering the respective ‘services’. This is a much quicker approach, less confusing for the Business, in what would otherwise be referred to as ‘boiling the ocean’.
What you will find, is that it is usually more than one functional area that is delivering a ‘service’, e.g., IT Incident Management service, the Control Centre is notified of an critical issue, by the Operator, who informs Communications who determines based on the criticality of the issue and the Users impacted, the messaging of the communications, who informs Customer department in the Contact Centre the messages and scripts to respond to queries from the public, and media. In that short example, you can see that there is more than one function involved, to deliver one service.
Had the ‘services’ been given or assigned to a ‘function’ as opposed to understanding what Business Capability was involved, down to the Process(es), and Process Owners where the actual work is done, and the ‘service is delivered’, you would have got all the stakeholders, inputs, process, outputs and customers (i.e. SIPOC) of that process(es) and service-delivery involved, and agreed, there would be no ambiguity or misunderstanding of who is doing what, how or why. There would be no gaps and ownership issues appear, which ultimately results in confusion, misunderstanding and a slow and troublesome attempt to implement ‘services’.
About HOBA Tech
If you liked what you read, learn more about Business Transformation and how to bring it to reality, with less stress, less effort, less time, less cost and higher profit. Lean the our award winning agile Business Transformation framework already used by thousands across the world to transform their business, including the UK Government, FTSE 100 Companies, and start-ups, check out here.
If you want to read why others are calling The Business Transformation Playbook, the “Business Transformation Bible” read the reviews on Amazon here or see its listing on The Business Strategy eBook List of All Time, click here.
Hope you find that useful. If you did, let me know in the comments below what you like and would like to see next, and share this with anyone you think would benefit from it!
Thank you for reading this!
Sincerely,
Heath Gascoigne
P.S. If you want to join our Business Transformator community of 2,000+ like-minded Business Transformators, join the community on the Business Transformator Facebook Group here.
P.P.S. If you want to learn more about business transformation, check out The Business Transformation Playbook here.
For more information, visit https://www.hoba.tech
