After almost 8 years of working and thinking together with Milan Guenther and the others in the Enterprise Design space we have taken some clear steps towards merging the Milky Way and the Enterprise Design Facets.
The Enterprise design facets
The facets represent different perspectives of the enterprise.
Enterprise Facets
Identity – who are we and why?
This facet captures the identity of the enterprise. Who are we? Why are we acting in a certain way? What values are guiding us? And what is the purpose of our enterprise? What stories are told in our enterprise?
Experience – what is our role in people’s life?
This facet captures how we design experience for people interacting with us. The journeys of the people and the most important tasks they want to get done are starting points for the design.
Architecture – what are we capable of achieving?
The architecture facet is capturing the structures of the enterprise that make it possible to achieve the wanted outcomes, results. The business processes and the business capabilities are the building blocks of the architecture and the Enterprise ability to deliver experiences driven by the purpose .
The merged overview – the geography
The merged version of the Milky Way clearly highlightes the facets in the map. The experience is a natural part of the map since everything we are doing in the enterprise supports the delivery of experiences and value for external parties. The center of the map is where the core concepts from the purpose facets are placed. There is also a possibly to be sector specific in the purpose description.
The way that we design the Milky Way capability maps makes the Business Capabilities supporting the overall Value Flow very visible. These Business Capabilities are, thanks to the use of the Business Geography, given a context and relation to other Business Capabilities in the value flow.
The Business Capabilities that are of a more supporting kind, like Security Management, Analytics, HR, Internal Communication, Administration, etc, are not possible to place in the Overall Value Flow since they support all or almost all Business Capabilities in the Enterprise. This means that we need to work with them in a different way.
This relation between Business Capabilities and supporting Business Capabilities is not unique for the Milky Way modeling but occurs when modelling Business Capabilities in other ways too. The supporting Business Capabilities will be refered to as Supporting Capabilies in this text.
The red Business Capabilities are directly supporting the overall value flow.
The blue Business Capabilities are supporting the all other Business Capabilities.
The way the Support Capabilities are supporting the rest of the Business Capabilities is hard to visualize. We usually place supporting Business Capabilities in a specific part of the Milky Map, if they are represented.
What makes a Business Capability a Supporting Capability?
When we define Business Capabilities we run in to some that could be considered either a Business Capability part of the value flow or a supporting Capability, an example could be “Analytics”.
The Analytic Capability could be considered part of the Follow up sector of the Value Flow and therefore be placed there. But we could also argue that “Analytics” ought to be part of all Business Capabilities and therefore all Business Capabilities should have the ability to analyze their own operation so no centralized, specialized Business Capability is needed for Analytics. We would capture the need for analytics in the description and expectations of all Business Capabilities.
Yet another way of thinking is that the Analytic Capability is a support Capability serving all Business Capabilities. Even in this scenario we have choices to make in terms of how we would like the relations between the supporting capability and the business capabilities in the value flow to interact. One way of designing the relation is to say that all analytic tasks are being performed by the supporting capabilities. Another way is to design a more detailed relation stating what is managed by which capability.
Our experience is that in most cases there is a sophisticated relation between the Business Capabilities and the Support Capabilities. The relation can be formalized or managed in a more informal way.
Bring a Product Portfolio and Development to the Support Capabilities
This way of thinking can, partly, be translated into a guide that helps us to make the formal or informal relationships visible and more “product/service driven”.
What is the Support Capability offering?
All Business Capabilities are offering other Business Capabilities services of different kinds. The once that are in the overall value flow and close to the Customers have a clearer view of what they are offering.
The support capabilities can make the services they offers others more visible by defining them and start to work with them in a service catalogue/portfolio way.
Base Services
The portfolio probably consists of a number of services that are fairly stable and reoccurring. These services can be defined as “Base services”. These services are offered to the rest of the organization in a way that is efficient and robust. The Base Services can be developed and improved by a close dialogue with the “Internal Customers” in the Business Capabilities using the services.
An example of a Base Service from an HR capability could be “Provide list of Recommended Recruitment agencies”, “Perform drug test of candidates”, “Draft Employment Contract for an existing position” and “Draft a Competence plan for employees”.
Add on/Emerging Services
There are probably also a number of services not so well defined and delivered in more ad hoc ways. These services are also most likely initially not offered to, but asked for by some Business Capabilities. These services can be defined as “Add on/Emerging services”.
These services are not as well defined or delivered in a standardized way since they are not as mature as the base services. These are also the services that create a lot of work and even confusion.
An example of Add on services from the HR capability could be “Hire 100 extra staff to manage extreme levels of staff on sick leave”, “Recruit or source a specific, very rare competence”,
Develope the Service portfolio and development process
If some of these add on services are starting to become reoccurring and more requests come for different areas of the organization then this is a signal that this service is a candidate to become a “Base service” to be offered in a more standardized way.
A development process identifying reoccurring addon services that can be “productified” and the stepds needed to turn them in to a base service offering can be set up to formalize this maturing of “add on” services to “base” services.
Areas of responsibilities of a Support Capability Owner
A person who is responsible for a Support Capability can have different levels of responsibilities for the wellbeing of the capability.
The overall responsibility spans from the daily operation of the capability, to maintenance, long term development of the offerings (the services offered) as well as the strategic direction of the capability driven by the overall strategies of the organization to which the capability belongs. (Inspired from the Viable System Model and the 5 sub systems of an Organisation. See https://www.amazon.com/Fractal-Organization-Creating-sustainable-organizations/dp/0470060565 )
Daily operation – customer servce deliveries, staffing, processes are functioning and delivering according to expected quality and lead times.
Long, semi long term development of the offerings – development of services based on customer needs, the development activities have a balance in terms of the time frames of the results being delivered securing a continues deliver of improved services to the customers/users. The internal business and/or IT development activities are linked to the new and existing offerings.
Maintenance – there are plans for maintenance and the balance between planned and unplanned maintenance activities is balanced according to the wanted levels.
Strategic work – a strategic direction for the Supporting Capability is developed in close dialogue with the “customers” and the overall strategy of the organization to which the capability belongs.
These areas of responsibilities are not specific for Support Capabilities. All Business Capabilities 2 need to work on these four areas to be successful over time.
When creating and using a model usually there is a metaphor behind the model guiding the user. The metaphor is not in plain sight but it is giving the boundaries, the expected behavior and the wanted state. In an article by Naomi Standford, (https://www.linkedin.com/pulse/models-metaphors-naomi-stanford), a number of metaphors of organizations are listed, mechanic, organic, a brain, culture, power game, etc…
In enterprise/business architecture the metaphor of the building or city and the drawing of it with all details described has been such a strong starting point. The underlying idea of getting hold of all details and manage them. This is not a metaphor that takes us in the right direction. This metaphor gets us to busy modeling and documenting the universe not enable change.
What if we tried to find a new metaphor for enterprise/business architecture? A metaphor that resonates with the new context of faster pace, more decentralized organizations, more networks, less clear boundaries and an exploring approach to change…
I have been thinking in the terms of navigation. How can we as architects create overviews, maps that helps people in the organization, the network navigate, find their way, understand the dependencies, create possible “what if…” scenarios and give the “how might we…” a connection to what’s all ready in place, …
The navigation is about navigating the complexity of the organization and the network it interacts with as well as navigation in time, possible futures.
When navigating what is the important stable thing that gives us a landscape to navigate in?
So I have showed how the Milky Way can be useful to see and understand all the perspectives in play. When we talk about the perspectives we refer to them as the three eco systems in play.
The external eco system with the customer, supplier and other relevant external actors and their interaction with our enterprise,
The internal eco system with all the internal business capabilities and how they interact to create value
The product/service eco system with the products, value streams and the building blocks, product components, needed to configure the wanted products/services.
But the insight of how the eco systems are interacting and together creates value is not enough. There is a time and development dimension missing.
Chris Potts coined the expression “Enterprise Inertia” and I can really see how slowly changes are taken from an idea, to discussions, to planning, to actual change initiatives and finally to the actual way of working. This dimension, time, is also one we need to navigate in.
We use this map, (6 field time analysis, in Swedish “6-fältaren”) when figuring out “when” in time we are with our Milky Ways.
By using this map we want to speed up the flow from an idea to it being release in to the current state, (the red arrow above). We are also aiming for a flow with less conflict and surprises and more learning, cooperation and innovation.
Usually when starting to make a Milky Way we start with the current state of the enterprise, what is it we do, in what order, what IT systems do we use when doing what we do, etc…
The next step is to map all the ongoing initiatives to the Milky Way. This is often a view many find valuable and the effort of creating it is small since most organizations know what change initiatives they are investing in. This view can be extended in to the planned change initiatives, the back log, using different colors for the ongoing vs planned initiatives.
To describe a wanted state is also not so hard. Highlighting the areas in the different eco systems then needs to function in new ways based on the strategies in play.
The hard part of getting a Milky Way accepted and used is to establish it as a valuable tool in the Gap analysis and the back log planning. This is where the politics and power games are strong and there is not always that a shared map is appreciated…
If we spend to much time mapping the current state, ongoing changes and the wanted state we might have a hard time getting invited to the actual decision forums. Our experience is that the sooner a Milky Way is used in the gap analysis, scenario creation, back log planning and as a basis for prioritization the better odds for the acceptance of the map.
In the process of getting the Milky Way established there is also a process of learning and uncovering how our Enterprise make decisions, what forums are in play, what dimension are valued, are there perspectives that lack representation. We then need to adjust the views to fit the questions and challenges of the different stakeholders and forums.
We also need to better understand how the development of new products, new customer experiences creates a need to change, improve or create new business capabilities in order to get the change flow going. The first step, we believe, is to see the different stages of the flow and what questions we need to answer in good ways.
The Milky Way was first developed and used at TUI Nordics back in 2013. Here is a short summary of what we did during the first years of usage.
We had a traditional IT / Business relationship, a not so fast development of new solutions, a situation with little overview which led to sub optimizing and conflicts and an internal focus. We moved towards a closer relationship between the business and IT, faster development with more product and customer focus using the Milky Way map as a strategy tool. The transition was done at the same time as a agile transformation of the organization was made.
An article describing some of the benefits (article)
Shared understanding and a tangible architecture
The result was a situation where TUI Nordics had a shared Milky Way, capability map giving all a shared understanding of how the enterprise was structured and how the different perspectives interacted.
A Detailed version of the Milky Way at TUI Nordics with the IT Applications and information flows shown.
Documentation that was created more in a form of guide book giving the readers the ability to navigate, find the right details and the right team to talk to. This way of presenting the architecture made it more tangible and accessible.
Use the Milky Way to create teams and make connections between the business and IT organization
The Milky Way helped visualizing areas of responsibility of each IT team and in some cases the map helped reshaped the IT teams to better support the business areas.
Get better portfolio overviews, support prioritization and scoping of initiatives
We were also able to use the Milky Way map to create better overviews for prioritization and scoping of change initiatives. During the first years the scope of the change initiatives change from being scoped based on the business capabilities to being scoped based on the support of a new value stream.
Increase the Customer focus and the connection to the internal organization
During these years we also saw the need for an even large focus on the customer perspective. We combined the original Milky Way with the customer journey and ended up with an overview that helped increase the awareness of how the business capabilities supported the customer journey driving the improvement of the customer experience.
High level view of the Customer Journey and the Milky Way map
In more detailed versions of the combination we added the current state and the wanted state of how each business capability supported the customer experience. This made it possible to connect the wanted improvements in the customer experience with the development of the business capability.
Detailed view of the Customer Journey, the business capabilities and their current/wanted state
Use the Milky Way as a basis for Business Model Comparisons
The strategic business architect used the Milky Way to make a business model comparison to better understand the strengths of TUI’s business model.
Use the Milky Way to understand the interplay between the Value Streams and the Business Capabilities
During the years there was a growing need to get a better understanding of the products, how they were delivered by the business capabilities and how the value streams were designed. There was also a conflict between the business capability owners and the owners of the product portfolio. The conflict was based on the two fundamentally different tasks and KPIs the roles had.
The business capability owner had the responsibility to increase efficiency, lower costs and standardize. The product portfolio owners was expected to develop and introduce new products and services using the existing business capabilities.
Since the new products and services were introducing new customer experiences the business capabilities had to be improved or new once needed to be developed.
We created this overview to visualizing the two perspectives in the same picture. The yellow circles around the business capabilities shows the areas of responsibility of the business capability owners. The blue line shows how the value stream of a product goes cross almost all business capabilities in the map.
From this overview we defined the responsibility of each perspective and we came up with a suggestion to how they could support each other.
Product line & Strategic Product Owner and Target architecture
There was a large architecture transition going on in TUI. All products were to be moved to the new architecture. Most of the product portfolios were quite similar but there was one exception. We did a number of scenarios for what the transition of this product portfolio could look like, the challenges and what the costs would be.
Based on this overview and more detailed view of the different areas of the map TUI made a strategic decision on how to pursue.
Here are some examples of what a Milky Way could be and how it is used. I hope these examples will give you a better understanding of the value of a model/map like the Milky Way.
A Milky Way webinar May 5th 2021 together with Milan describing the merging of the Milky Way and Enterprise Design facets
Well most of you probably think of the stars on the night sky but this is not what I meant. There is a connection but I will come to that one later.
A Milky Way map is a map that describes an organization or a network of organizations using business capabilities, customer (or other relevant actor) journeys, value streams all positioned on one page.
The Geography of the map – Business Geography
The position of each part is as important as it would be on real map of a city och a country. However there is no north or south in an organization so we need something else to give us the geography. In the Milky Way map we use the overall value flow to give us the geography, the business geography.
We have created a circle, a hub representing the value flow in the map. The reason for the circle is to give the mental model of us doing things over and over again, like most organizations does. The more traditional way of structuring business maps, i.e. process maps, application maps, information models etc usually have a linear structure, from left to the right with no obvious feedback loop.
The linear way of structuring a map and the circular way of structuring a Milky Way map.
The Business Geography with the hub in the middle giving each sector of the map a business context.
Items in the Map – The Business Capabilities
Important pieces on the map are the business capabilities. In this context we use the business capability as a container for everything that is needed to be able to perform the tasks of the Business Capability.
I.e. the “Pricing” business capability is responsible for the pricing of products and services. You will find the following within this business capability; people working with pricing, their processes, the IT system supporting the pricing process, specific business rules relevant to pricing, if relevant even specific locations, the business events/results the processes creates and more relevant things for the business capability in order to be able to perform the tasks.
Business Capabilities communicates with each other through information services. All (I can not think of a capability that lives in isolation) capabilities needs services from other capabilities.
The communication can be done in all types of ways/channels, from an analog conversation with someone on the other side of the table to a super sophisticated micro services architecture with services and APIs instantly signaling when a relevant business event is to be shared, i.e. “new product available to be priced” or “new product priced”.
The position of each Business Capability is based on where in the overall value flow the business capability is creating value for the organization and the customers.
The plain position gives a lot of additional information for persons with knowledge of the business geography even if they do not know the pricing business capability. The position in relation to other business capabilities is also relevant to understand the dependencies between them, by design or by “coincidence” (it just happened…).
The initial Milky Way maps we did really reflected the fact that we, at the time, had a very internal focus, the processes, information ans IT systems of the organizations we worked for. There was a need to open up to the customers and their experiences.
We merged the Milky Way and the Customer Journeys by using the Business Geography again. The Customer Journey with the stages and the touch points describes how the customer is interacting with our organization. The Milky Way describes how we are structured on inside with the business capabilities and the relations between them.
Now we want to see which customer touch point is supported by which business capability.
Items in the map – Value Streams
We started by describing the Business Geography as the overall value flow of the organization. Now we are returning to the value created. This time we want to be more detailed. Instead of looking at the overall value flow we zoom in to different value streams creating and delivering different products or services to customers.
By value stream we mean all the steps of value creation a product or services is taken through from the initial idea to the sales, delivery to the customers and follow up of the performance.
Now we take value stream and add it to the Milky Way by drawing the value stream in the map creating relations between the business capabilities adding value to the product/service from the initial idea to the follow up of the performance. Different value streams might use/need different business capabilities depending on how they are design/build/delivered to the customers.
Now all the communication channels and messages that the business capabilities communicated have a purpose and can be connected to one or many value streams of different products/services.
All products and services have a life cycle and the stages in the life cycle require different types of support from the business capabilities.
The stages are, innovation & development, introduction, growth, maturity, decline and replacement.
The support needed for a new value stream is quite different to the support a mature value stream needs. This is a good way to connect the business development needed to the product/services portfolio.
If we let the customer needs and our product strategies drive the business development then I believe there will be a better outcome then if we were to let the business development and product strategy and development work in a silo each.
When I entered the field of business architecture in 2006/7 I came from a background as a business controller gone business developer, forced to at least understand IT and information structures. I studied psychology for a year during a maternity leave with a focus on cognition and knowledge creation among other things.
I had also meet really experienced product lifecycle management consultants with long experience from both Ericsson, a large telecom company, and Scania, https://www.scania.com, early in my consultantcy carrieer. They showed me how a product or service is created based on market/customer needs, developed, sold, delivered and maintained by the processes in the company and/or by the partners in the network.
In 2012 I worked as a business architect and even trained other professional in business architecture, information & process modelling and architecture planning. But the tools I used felt too thin, the questions we tried to tackle were all related to getting an overview, to document the current state. All of this way too far from the customers.
A growing feeling of doubt came over me, there must be better ways of addressing the challenge of how large (and not so large) organizations can evolve and prosper over time then the one I was using.
What if we tried to create better overviews where all, almost all important structures were visible and related to each other? Visualizing the dependencies skilled architects saw but had such a hard time describing to others.
One important part of the puzzle, the business capability concept, entering the scene in 2012 made the first steps towards the Milky Way easier and in heinsight obvious. Instead of being forced to create overviews of each perspective, information, process and IT systems we could combine them all in one business capability map.
My first attempt to place IT applications in a business capability and relate the position in the map to where in the value flow the capability provides support. It was really a case of exploring and trial and error….
The first draft of a business capability with supporting IT application
First hub visualizing the value flow of TUI Nordics. (The same stages are valid today)
An other thing paving the way towards something new were a number of large architecture initiatives following the old game book with a lot of upfront planning and documentation failed badly.
There was a search for new ways of doing architecture. Less documentation, less upfront planning, better visualizations, easier to communicate, support scenario planning, tighter cooperation with the developers, both business and IT developers…
So we started to explore “how might we make architecture more valuable by making it easier to understand, communicate and really useful while developing, shaping the organization for the future?”.
The next post will describe more about the Milky Way map, what it consists of, how it is structured and some initial first situations I used the map in the very beginning.
A lot has happened since the last post in 2015. This new way of thinking and working with Business Architecture is not so new anymore. We are still working with the Milky Way model, business capability map, still improving, adding layers and perspectives to it.
Four years of working, teaching and thinking has moved our understanding and experience from a focus on “managing and understanding all the parts in play med their relations to each other” to “how do we design, create a possible future based on what we want, what we have and what the world wants/needs in a sustainable way”.
This has made us more aware of the perspectives in play.
The wider view of what we need to know, understand and take in to account, more customer focus, more external drivers and the product/service perspective.
We have also explored what design is and how we can benefit from this, for us, new way of thinking.
The increased change rate thanks to the agile at scale way of work has forced us to adjust our way of work and our tools to facilitate faster feedback loops from decisions to results and back again.
The Milky Way map is still a valuable tool to us, our clients and the clients taking our architecture trainings.
In a number of posts I will give the background of the Milky Way, how the thinking has evolved and what I see in the future to come.
The first draft of a business capability with supporting IT application
First hub visualizing the value flow of TUI Nordics. (The same stages are valid today)
Business Architecture in a new way with new friends 