There are so many enterprise architecture frameworks. And so many discussions about their value: what framework to use, how to tailor it to your specific situation, do’s and don’ts and these discussions will go on forever. The question that actually drives these discussions is a more fundamental one than we think and possibly related to finding the "bigger truth" behind using enterprise architecture. The promise of enterprise architecture is so inspiring and could potentially bring so many benefits for the enterprise; but how to make it happen? Where to start and are there practical “ready to go” instruments we can use?
To some people that bigger truth is also related to finding out the key structures and patterns to apply enterprise architecture in a meaningful way. It is a quest on a “meta-level,” focusing on processes, structures and mechanisms to make enterprise architecture (EA) work and make it fit into the dynamics of an organization. To an, we suppose, larger group of people, the key question is related to the practical process of performing enterprise architecture in a real life. On the coal-face level, the feet in the mud kind of mechanics that practitioners are interested in. We could probably re-phrase that into: “Show me the tools and practices that I can use to apply enterprise architecture in such a way, that I can reap its benefit as soon as possible; and that in parallel help me to build the benefit case as to why EA makes sense.”
In our line of work we at Digital Innovation see many professionals and organisations struggle with this. We see EA teams being accused of having the “ivory tower” mentality and so many EA practitioners being told that they are too far from reality.
In addition, they are being confronted with stakeholders that tell them that EA output is delivered too slow, that their work is difficult to understand and that it does not relate enough to the real challenges opposed. These architecture teams are in a vacuum, more or less detached from the organization and in the end, the EA value case will slowly but surely dissolve into “another brave attempt to align business and IT – but it did not work out.” This is a shame because EA has the potential to align an organization throughout its full scope, not only business and IT, but across all of the organisation’s elements and concerns. Horizontally across its functions and, most of all, vertically across its strategy, tactics and operations.
However, we also have met some organisations who are very successful in their EA endeavours, regardless of the context EA is in (being transformational or operational), and we at Digital Innovation have been thinking about the reasons for their success.
Success in enterprise architecture endeavours
First of all, it seems there is not a “grey area” of success – either an enterprise architecture (EA) function is successful or it is not. What also is interesting is that these EA teams all seem to be labelled as the “go to guys in case of problems” (which triggers another problem: that all kinds of questions land on the EA desk, several of them not really relevant to their function, but let’s not go there now). They are the guys that have a broad overview and when required, can deliver enough insight and detail to connect the dots and, even more importantly, have shown the ability to deliver fast. Being able to deliver fast seems to be very, very important. They are pragmatic, result-oriented, masters in pin-pointing the core essence and also show a high business-acumen.
Thirdly, they all do a lot of “marketing” around their work that is not only “eye-candy slideware.” Their communication is created in such a way that it is compelling to business people – they understand it. They do not talk so much about EA or about the framework they use (think of the TOGAF-certified mark attached to the EA credentials), but they try to resonate with actual business challenges, such as how focused they are on helping to achieve (top line) growth, lowering (IT) costs and how, for example, to enable workforce automation to optimize operational efficiency and operating costs.
However, the most common denominator for successful EA teams is the existence and usage of a user-oriented process that is well understood, that is transparent and super-executable.
This process clearly stipulates the “How We Do It”-question (the steps we are going to take you through and the result of each of the steps) and it is geared to resonate the top of mind business expectations towards the strategic design function that EA is. The main reason for its successful adoption is that the process truly involves stakeholders (users), by using a well-framed process, which is based on interaction, exploration, agility and iteration.
This got us thinking. What defines a “good process”? Can we find examples of such a process in other practices? If we are able to step out of our (rather technical) comfort zone and if we really open our eyes, what can we see in the world around us? One specific approach really got us interested: Design thinking, invented by David M. Kelley, founder of IDEO. Design thinking expresses a view of addressing intractable human concerns through design. As this article is not meant to give a study about design thinking, let’s try to cut a long story short: In business, problems most commonly are solved by conventional analysis which is linear most of the time (what you learn during an MBA), while designers problem solve by synthesis, which is a process of divergence, convergence and prototyping – and back, thus cyclical (what you learn at design school).
Designers have a very clear focus on users of the product or service and see them as critical to come to a meaningful product (form and function), even to that extent that they embed users into the design process itself in order to co-create the result. The design thinking method shares a common set of other traits: creativity, ambidextrous thinking, teamwork, curiosity and optimism. If you ask us at Digital Innovation, that is quite the contrary of what you can experience in an average EA practice or workshop. So a design-thinking process applied to EA, what does it look like?
What does a design-thinking process applied to EA look like?
Imagine, as an enterprise architect (EA), you have a problem to solve or a concern to address. Assume that you are not confronted with solutions already figured out for you (“Please design a document management system for us”), and that you are in the position to talk about the problem itself (“We want to be able to collaborate better”). How would you solve this in terms of approach and working process?
Have a look at the following visual (which is rather abstract and holistic, but hopefully it still contains enough detail to support you in assessing it for your own usage, have a look here to see what we mean) and find out if it makes sense to you. We took a classic definition of the design thinking process and tried to customize it for usage in the enterprise architecture context.
(Original design thinking process visualization is courtesy of d.schools.)
The design thinking process conventionally has three phases: (1) Inspiration which we have rewritten as the Inform phase, as in the EA context it is not so much about re-iteration of the requirements but it is about getting the drivers crystal clear. The (2) Ideate and the (3) Implement phase we have left untouched.
Per phase there are three steps with some loopbacks within the phase, as well as there are cyclical loops and iterations between phases.
In the Inform phase we have the following steps:
Understand context and purpose Here the EA tries to get an understanding of the context and the purpose of the requirements. Context here means the Business System/larger business scope that the requirements are impacting. This can be done through a network model, or cause/effect diagram. This analysis only renders one “state” – the context is what it is and in most situations cannot be changed. With purpose we mean a statement or set of statements that justify why a certain solution is required. What should it bring? A short paragraph, ideally following a SMART structure, can help. Multiple statements (purposes) can exist.
Define users, drivers and objectives Users: who are the human actors that will use or that will be impacted by the product? What are their drivers and what do they want to achieve with it? A stakeholder analysis, including a RACI, can be very helpful. A good approach to this step is observing the users. Not only noting down what they say their drivers are, but also seeing the unseen by observing them in their day to day work. From their behaviour you might also define new objectives. It is good practice to validate your observations and insights with them before proceeding to the next step. And it is perfectly fine to go back to step 1 if you require that.
Create viewpoints and (success) criteria Based on the previous step, you can create viewpoints, in design thinking called “Personas.” Instead of making heavy, conventional architecture perspectives, you can use User Perspective Cards (UPCs), which tell more of a story than listing structures and showing matrices. Via the UPCs, you can also list success criteria, that tell us what a product or a service should do in order to be satisfactory for a certain user. In most situations, you will have multiple UPCs and an extensive list of success criteria (tip: you can merge the criteria into one aggregated list to make it accessible better – these success criteria are important pieces of information for the following steps). It is perfectly fine to go back to step 2 if you need to do that.
In the Ideate phase these are the steps:
Ideate on solutions You now can start figuring out possible solutions. Try to list as many as you can, there are no constraints here, but try to stick to the success criteria. At least three ideas should be taken to the next step. This is the actual creative piece of the work – brainstorming, trying to think out of the box, conceptual drawing, voting and trying to achieve a consensus. We at Digital Innovation have found out that a good method to support the brainstorm process with a structured method is Lean Coffee.
Prototype selected ideas Try to put your ideas in practice and see if they work. In architecture jargon these probably are the good old proofs of concept (POCs). There are some pre-requisites here, if you are operating in the IT space. You need to create an environment that is much like your production domain, but that has no or as less as possible governance and procedures around it that could become inhibitors for your innovation process (as this is what Prototyping actually is meant to do – driving innovation through hands-on exploration). What you do need are applications that are related to the new product, datasets and states (integration behaviours) that are as close as possible to the as-is production state, so that you can prove your prototype will actually work in a real (or close to real) context. Try to deliver at least two prototypes.
Test prototypes with users During this step you involve your users again to test and validate the prototypes you have created during the previous steps. An important document to use is the list of criteria created during step 3, as this list concretely defines when a prototype is successful and when not. Create a quick checklist based on the criteria. Very important here is that you observe your users while they are working with the prototype. Again, you must try to see what you do not see – the kind of stuff you will not find back in formal documents.
In the Implement phase the following steps are present:
Create context Once you have selected the best prototype and solution, you need to think about the context around the product (or service) you will launch. What are the constraints, pre-requisites and enablers that you need to manage to make the product actually launch successfully in “production”? Think of release processes, security guidelines, integration rules, ownership and governance, etc. Sometimes you will encounter so many inhibitors that the project would be dropped in a normal situation. However, you have gathered so much buy-in from your stakeholders through the design process that you probably can count on enough support to drive the product further. If you encounter issues that seem to be unsolvable, try to inject these issues into a new design thinking process to find out if there are any solutions for the problems opposed to you. If the product brings enough business value, it might also be that the contextual constraints will be solved through executive power. Make sure you list the impact of these changes (combinatory effects), as they could affect other products in services that are already in “production.” Remember that as an architect, you can influence decision-making and politics, but these areas are not your responsibility or concern – you are a designer, not a manager and your goal should be to deliver content to support and enable change, not performing the change itself.
Pilot selected solution The pilot phase is more or less a “pre-production” phase, where the product is launched in a contained, controlled test area (a selected group of users, a certain business, a certain market). You can now find out if the product actually works as expected and if the product is fitting into the enterprise context correctly.
Launch solution (in productive context) Once you and your users are convinced that the product works, and everybody is eager to move, you can launch it to the production environment. Keep in mind that it is very likely that new requirements will pop up soon as an effect of this event, so stay attached and keep observing the users.
Final tips
It was not our intention to deliver a fully worked-out framework on how to use design thinking for enterprise architecture, but we hope that with this setup, we at Digital Innovation have kickstarted a thinking process on the benefits that design thinking could have for enterprise architecture – especially answering the “How to do it”-question.
We know that you now might have many further questions regarding this approach. Maybe about timing aspects (we would say, time-box each phase to a maximum of two weeks), about managing the process (think about using Agile and SCRUM) and maybe about things such as ownership (think of adding product owners, ideally selected from your user group).
You also might have questions about its application areas. We think that this approach might very well work within transformational contexts, but we can also see it being tailored to fit more operational circumstances, or even be customized to a specific, standard “EA way of working” that could become a common process to apply when using enterprise architecture.
The point that we try to make is that we need to think about making enterprise architecture more exploratory, user-oriented and creative, embracing change and using divergent – convergent thinking. And that by doing that we can come to a more prescriptive process on how to make EA actually work – apart from abstract, difficult frameworks with generally low business appreciation.
Comments