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.
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.
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 