Keep IT Clear, Keep IT Simple

Draft Complexity Article 1 Keep it Clear, Keep it Simple! How an easy-to-use technique can transform business/IT communications “Simplicity is the ultimate sophistication”, said Leonardo da Vinci. Yet we have been wrestling with the problems of language and how to communicate concepts ever since humans learned to talk. We appear to be attracted to the eloquence of prose and proud of our ability to conduct academic discourse. But this clutters our thinking and buries the very idea we wish to communicate under confusing terminology and obscure language. It is almost as if we avoid simplicity at all cost; our desire to talk the language of our profession outweighs any thoughts of simplification and ease of understanding. Nowhere is this "profession-generated" complexity more prevalent than in IS architecture. This article suggests two ways to introduce simplifying techniques to IS architecture. The first is a language which is used to simplify the communication of business needs to the architects and architectural content to the business. The second suggests a simplifying communications style for Enterprise Architects. So what can we say about ‘unwanted’ complexity? Some complexity is unavoidable and maybe even desirable: I’m pleased to know, for example, that there are professionals who can fathom the complexities of the flight management systems that keep the aircraft I’m in aloft. I do not, however, need to understand the design of such systems to appreciate their value. The problem in business, however, is that the language of IT has crept into the way businesses describe and shape their requirements of an information system, which steers the discussion between business stakeholders and IT specialists towards the IT-how rather than the businessoutcome-what. How often do we hear so-called business requirements expressed in the language of IT? How often do we hear business sponsors and end users talk about applications and databases rather than the business outcomes or operational support they need? This use of IT language often means dialogue between the business and IT often starts wrong-footed. The use of technology language by the business either frustrates the IS practitioner who genuinely wants to understand their business needs or pushes a particular solution before the requirements are fully understood. To make matters worse, so-called business requirements, even when expressed in business language, are often way too narrowly focused on the detail of feature and function and ignore other critical aspects of the overall business information system affected by the change. The users often dwell on the minutiae of a work task or the placing of an input field on a screen rather than the end-to-end flow of events and outcomes. This leads to another example of ‘unwanted’ complexity – the complexity of detail-too-early and inappropriate ‘binding’ of functional requirements (the anti-pattern of Information Hiding Principle established by systems theorists and adopted by software engineers at design time - http://en.wikipedia.org/wiki/Information_hiding ). For IASA newsletter Nigel Green, Capgemini, 2007 Page 1 of 11 Draft Complexity Article 2 Furthermore, because of the high degree of specialist knowledge required to understand the myriad of technologies available today, business people often find themselves lost in IT concepts. From the business point of view, the IT guys can seem to over-complicate things, particularly when the useful IT they use at home or on the web may seem much quicker and easier to use. From the IT specialist’s point of view, they can find the requirements discussion hampered by this perspective: they are often left with the feeling that ‘a little knowledge is dangerous thing’. This is just one example of many frustrating discussions – for both parties – that take place across the business-IT boundary, and caused primarily by unwanted complexity and obscure language. So, how do we tell the difference between ‘unwanted’ and ‘wanted’ complexity? An example of unwanted complexity is anything that requires the business stakeholder to adopt an unnatural way of expressing their needs from their perspective (like, for example, database schema or state transition diagrams). Another, as mentioned earlier, is the inappropriate dive into functional detail too early. Both the IT practitioner and the end user are guilty of committing both these sins. This unhelpful stuff is not to be confused with the genuine complexities of the behavior of the business domain being addressed. As mentioned earlier, some complexity is a fact of life and some systems are inherently complex. Understanding the need to support this complexity is vital to delivering the IT solution – this is ‘wanted’ complexity as it reflects the real-world situation. But even this ‘wanted’ complexity can be described using simple language. What’s being obscured by such unwanted complexity and poor communication? Simply: • the desired business outcomes • and the barriers to adoption of the required change. Both are being buried under unhelpful language and poor communication. Enterprise Architects can and, in my opinion should, simplify communication and, in doing so, think carefully about how can they develop stronger bonds with the business stakeholders and their desired business outcomes. I believe that this is an essential first stage before we dive into our preferred IT language of architectural frameworks and methodologies. Instead we should concentrate on creating a simplified dialogue with the business in a language that: • • • • maintains the focus on business outcomes considers the adoption of the desired change up-front provides a framework for the discovery of architectural principles helps focus in on the areas that need to change and where functional decomposition is needed. This simplifying language needs to be applied early in the project lifecycle in what we might call the abstraction phase or iteration in the change project. This is a period of group discussions, For IASA newsletter Nigel Green, Capgemini, 2007 Page 2 of 11 Draft Complexity Article 3 whiteboard scribblings and airing of stakeholder frustrations. This is where the enterprise architect builds a rapport with the stakeholders and can start to work on building a trusting relationship with them. In the business world, many easy-to-use analysis techniques exist that are accessible to all and are in common usage. For example, SWOT Analysis - a technique that examines the four dimensions of Strengths, Weaknesses, Opportunities and Threats applied to a current business objective. The technique is credited to Albert Humphrey, who led a research project at Stanford University in the 1960s and 1970s using data from Fortune 500 companies. (see http://en.wikipedia.org/wiki/SWOT_analysis for a full description). SWOT Analysis is extremely simple and yet powerful for achieving consensus on the shape of a business initiative. Something analogous to SWOT is required to help us with business/IT collaboration. The primary aims of such a technique would be very simple: • • for the business: to be able to express its desired business outcomes in an IT meaningful way For IT: to be able to express solutions in a business meaningful way In contrast to usual business/IT dialogues, what’s needed is a business-natural language that moves the focus away from any technologies and towards business behavior – as expressed in values, policies, real-world events and any type of information being exchanged. Such a language will replace the familiar IT terminology of applications, databases et al and helps focus discussion on the key outcome-affecting aspects rather than functional detail. An example of such a language (and abstraction technique) is called VPEC-T (“vee-pec-tee”), after its five dimensions; value, process, events, content and trust. It aims to provide a “thinking framework” for expressing ideas that can feed existing architectural methods such as Zachman or TOGAF. VPEC-T focuses on the analysis of people and events by identifying the behavior and interaction with IT systems around the five core principles – see figure 1. For IASA newsletter Nigel Green, Capgemini, 2007 Page 3 of 11 Draft Complexity Article 4 Table1: The five core dimensions of VPEC-T Dimension Applying emphasis and techniques to: Understanding the values and desired outcomes of the business as a whole, business units and individuals, including those you interact with. Values can be thought of as constraining beliefs (e.g. ethics) and goals (e.g. desired outcomes). The rules that govern and constrain how things get done, including internal policies, legal and regulatory requirements, and external contracts across the business. The real-world proceedings that stimulate business activity – sometimes in a pre-defined sequence but often not. These are the triggers for action. The documents, conversations, or messages that are produced and consumed by business activities. These are the dialogues we use to share a plan, a concept, a history, and/or the details of a person, place, or thing. How to foster trust between all parties engaged in a system of value. Trust changes over time, and understanding and fostering trust relationships are critical to useful IT. The deeper the trust relationship, the more values will be authentically disclosed and declared. Values Policies Events Content Trust For IASA newsletter Nigel Green, Capgemini, 2007 Page 4 of 11 Draft Complexity Article 5 Using the VPEC-T technique, you can examine and understand the effects of any given set of desired business outcomes. Equally important, you can describe and present those effects in business-friendly language, using familiar office document format (no special tools needed). As a result, this technique can generate new insights that provide more complete business context to enterprise architecture. Figure 1: VPEC-T defines Information System Behavior. So how does VPEC-T work? As an example of applying the VPEC-T technique, think what happens when you are defining the guiding rules—the principles—for a business transformation or new enterprise architecture. Imagine a workshop initiated to derive such principles. The facilitator writes up the VPEC-T dimensions on the whiteboard and suggests that the group keep these in focus while discussing potential principles. Next, she writes up four headings on separate flip charts: • • • • Business Principles—the business drivers that define the need for change or business rules constraining the change program. Governance Principles—the guiding rules about who will make what decision in delivering the desired change. Solution Principles—statements that constrain the solution design and implementation. Tension Points—points that create risk to successful implementations due to, for example, differing values or conflicting policies—they may be irresolvable, but must be recognized and managed. It’s worth noting here that it isn’t necessary to organize the principles under the VPEC-T dimensions—just use them as a guide for arriving at a principle. Our imaginary facilitator then explains that the group should think about principles in the three categories and make a note of any tension points that arise. She suggests that the group look at tension points at the end of the session, and for each point, decide on an action to: For IASA newsletter Nigel Green, Capgemini, 2007 Page 5 of 11 Draft Complexity Article 6 • • • • negotiate and resolve, accept and tolerate, innovate to resolve, escalate to a higher authority. The value of this type of discussion, structured and facilitated using VPEC-T, is in: a) the collective understanding of the derived principles and b) achieving an agreed approach to tension-point resolution. The information gathered provides a stronger foundation for further work, such as the development of an IT Strategy, Enterprise Architecture, or the outcome-affecting considerations for a business transformation program. Here are some examples of the insights gained from a VPEC-T analysis that inform the creation of principles: • The impact on IT of differences in the Value Systems which affect business operations across geographies. • The value of common Business Event visibility. • The need for stronger business/IT policy governance. • The recognition of the need to improve Trust Relationships to remove adoption barriers. • The need for a focus on Content standards and Policies for specific information exchanges and identification schemes (such as People, Objects, Locations, and Events). Further examples how VPEC-T is applied (at different levels of detail and at different stages in a change project) are described in my book “Lost In Translation” (link at the end of this article). Here’s what a few practitioners say about using VPEC-T: • "Understanding Values was critical to help everyone understand there was a need to really consider the cross-company blueprints (enterprise architecture)–the absence of which had been blocking previous change attempts". “We’d all been assuming we’d been speaking the same business language in each business unit. But we hadn’t. Where policy wasn’t informed by a common factor–e.g. an external international standard–the resulting language wasn’t common, either. Without VPEC-T this would have been missed. I’ve talked to friends in other companies, and it turns out this is a really common problem. Obvious, and yet at the same time obscured by assumption”. “You’ll find that there are a lot of ingrained attitudes in IT, and you can trace them back to not thinking in terms of VPEC-T. Once you get IT and business personnel thinking in terms of Values and the context level, and what’s changing in the Values, the practitioners understand that “we have to reorganize.” “The way in which people analyze the business today–and specifically systems of the business–is too myopic. They take too narrow a focus, because the tools they have make • • • For IASA newsletter Nigel Green, Capgemini, 2007 Page 6 of 11 Draft Complexity Article 7 them take a narrow focus. And when you use VPEC-T, it broadens the number of dimensions you use to analyze the problem”. • “We had Trust relationship issues between the business units and the divisions, and the divisions and group. We had this really complex sort of dynamic, and a number of tension points surfaced. And when you’ve got tension points, you’ve got to do something about that. You have to decide whether you’re going to tolerate, negotiate, innovate, or escalate them. We found that, by understanding and discussing the tension points head on, we are now engaging in a genuine shared effort for a genuine shared business strategy”. “VPEC-T makes you go back and revisit the business goals under a new lens. It makes you realize things can change from where they were 20 years ago. This is actually enabling business transformation to occur, when, before, looking at it through a technology lens, it was actually impeding business transformation”. “With the VPEC-T dimensions, we now have the basis for a much, much more meaningful discussion around information systems architecture, which may lead to a much more informed, intelligent, adoptable, and cost-effective IT architecture”. “VPEC-T provides practitioners with the ability to put together succinct statements around some pretty complex issues“. • • • VPEC-T is not a replacement for tried and trusted business process modeling and IT engineering methods, rather it provides an uncomplicated, unifying, business/IT language to complement them. It is specifically designed to support better business/IT collaboration, allowing more relevant and timely executive decision-making on the use of IT. VPEC-T analysis is designed to foster the broadest possible communication. It is specifically focused on board-level communication to enable early-stage decision making before significant IT investments are made. At the simplest level, VPEC-T thinking can help derive principles that support IS strategies and provide guidelines for IS architecture. Many IS architects understand the importance of such principles and have been taking a principle-led approach for sometime – so what’s different? Using the dimensions of value, policy, event, content and trust to guide the thinking and test the emerging principles (applied in a similar way to SWOT Analysis) helps to ensure that outcomeaffecting aspects are covered. Perhaps more importantly, tension-points between differing values/polices between organizations and their associate trust relationships are identified. The VPEC-T approach contrasts with more detailed, technical and, therefore complex discussions that have an early focus on IT. These tend to drive the analysis of the business problem towards functional decomposition, data modeling, notation and tooling – all of which shift the focus away from the required business outcomes and adoption issues. IT architecture For IASA newsletter Nigel Green, Capgemini, 2007 Page 7 of 11 Draft Complexity Article 8 and engineering techniques are designed to drive completeness and precision, and introduce a language that is hard for the business to understand. This can result in frustration on both sides of the business/IT divide with neither party understanding the needs of the other. The sheer volume of information produced during the engineering life-cycle means the overall business context gets lost in the production of wiring-diagrams and technical schema. The complexity of the task requires a high degree of technical specialty that can lead to a lack of focus on the nuances of real-world behavior and human interaction ‘on-the-ground’. Often the focus is slanted towards engineering ‘how’ rather than the business ‘what’, i.e. the intended business outcome. For IASA newsletter Nigel Green, Capgemini, 2007 Page 8 of 11 Draft Complexity Article 9 A Communication Style for Enterprise Architects: So far this article has focused on the VPEC-T technique. But that’s only part of the picture Enterprise Architects must also become champions of simplicity and big-picture thinking in the way that communicate by: • simplifying, arbitrating and consolidating requirements across all aspects of the business but with the top-of-the-office business outcomes front-of-mind • identifying repeating patterns of business activity and seeking out opportunities for shared competencies and services • focusing on the behavioral aspects of the business that so often prove to be barriers to adoption of IT solutions; these include the hierarchies of personal and collective value systems and trust relationships • discovering the elementary aspects of the businesses information system - such as the rules and constraints embedded in policies, the business meaningful, real-world, events of interest and the information content being exchanged between individuals and groups • communicating the business ‘what’ without reference to the technology ‘how’. The above guidelines help to maintain focus on the reality of the business operation and the desired business outcomes of the change project. They help steer the business/IT dialogue away from distracting and poorly timed discussions about technology, and help focus on what needs to be achieved. Moreover, if used in conjunction with a framework like VPEC-T, barriers to change and tension-points – including those that are often obscured or glossed over - are revealed early. The resulting business/IT dialogues become the basis of an easy-to-comprehend storyboard for the desired business change. Enterprise Architect should be convincing and credible storytellers. And it also helps if they are proficient cartoonists. I’m not saying we Enterprise Architects need to create Dilbert-like cartoon strips – but we can take a few lessons from Dilbert’s creator, Scott Adams ( http://en.wikipedia.org/wiki/Scott_Adams ). Comprehension not Indigestion Cartoons and other visual media are a powerful way of communicating often quite complex, and sometimes contentious issues, simply. What is more, cartoons can be used to storyboard business reality without the need to train the audience in formal modeling techniques. The objective is always the same: to create the 'Reader's Digest' version of the architecture that is commonly understood and doesn't give the business IT-induced indigestion! We architects must learn to become comfortable with the journalists’ technique of ‘Simplifying and Exaggerating’. It’s much more important to convey a highly simplified message about a complex problem to the business stakeholders than it is to demonstrate our grasp of the complexity. We must become proud of our ability to distill and communicate the important opportunities – and the barriers to change. For IASA newsletter Nigel Green, Capgemini, 2007 Page 9 of 11 Draft Complexity Article 10 Simple yet powerful examples of cartoons and visual media can be found on the likes of YouTube.com: • • The Machine is Us/ing Us : http://www.youtube.com/watch?v=NLlGopyXT_g&feature=related and slideshare.net – VPEC-T trailer: http://www.slideshare.net/capgeminimedia/vpect-the-movie-book-trailer-edit6/ By killing unwanted complexity and developing their storytelling skills the Enterprise Architect can find unexpected trust relationships developing with business stakeholders and technologists alike. And simplified communication almost always earns the respect of senior business stakeholders. In the words of a senior UK government official, talking about such a "simplifying" enterprise architect: "For the first time in the five years of the program he has been able to explain and present the technical concepts to the diverse stakeholder community that the program reaches. He can pitch in terms of both technical depth and business enablement in such a way that you can see a thousand light-bulbs illuminate the room.” Whether considering how to approach business analysis or how to communicate IS architecture to its stakeholders, perhaps we should be aware of unhelpful complexity and the loss-intranslation that can happen across the so-called business/IT divide. Perhaps, like Leonardo da Vinci, we architects should wholeheartedly embrace simplicity and see it as the ultimate sophistication. For IASA newsletter Nigel Green, Capgemini, 2007 Page 10 of 11 Draft Complexity Article 11 Simplifying communication across the business/IT divide is the subject of Lost In Translation, a book I co-wrote with a colleague, Carl Bate. This book shares our personal experiences and the insights of other practitioners of simplified business/IT communication. More information can be found at http://www.LiThandbook.com Nigel Green is an executive enterprise architect at Capgemini. For IASA newsletter Nigel Green, Capgemini, 2007 Page 11 of 11