EA Voices

My last posts have been very much focused and following a red line, so now I am trying to pick up some loose ends. There is one thing which bugs me quite often when I am doing Enterprise Architecture work. There is way to much focus on talking about Enterprise Architecture. Something which is also reflected by following twitter post:

I suspect that the primary job role of Enterprise Architects is to argue with other EAs about what #entarch is. Prove me wrong, people.
— Kevin Brennan (@bakevin) 7. Februar 2013

My personal observation is that Architects actually discuss about Enterprise Architecture, but do in most cases not argue. This is a differentiation I find very important, because an argumentation chain would at least provide a red line why one approach is chosen over the other. By looking at the pure amount of frameworks and tools in the market and the amount of new players entering that space it is quite obvious that Enterprise Architecture is at the moment in a hype or fever situation. This can easily lead to total irrational decisions. On this topic I recommend to take a closer look at the Tulip Mania, some of the behaviours might also be seen in more recent crises.

Here (as mentioned before) I use GLUE as mapping tool for me. The real most interesting (and relevant) question for me always is: Where is a person stuck in the GLUE circulatory system.

And then I try to go into that position, placing myself onto the seat of that particular person to understand where the missing links are. If I manage to understand a portion of it I try to show the traces by using whatever terminology is approbiate for that particular person. Not GLUE, not a specific framework, but whatever language element helps. Sometimes indirect communication by others is the only way to succeed, sometimes I need to play over time. Invest today, harvest in a couple of month when a small trigger has grown into something powerful.

In most cases showing the connections to other information streams (in the circulatory system) allows the person at hand to see some possible answers to concrete problems which have not been solveable before. And there is one thing I know, then it is that I do not know anything, but what I know is that I am an Enterprise Architect. So in most cases I have literally no chance to give a correct concrete answer even though I am fairly often asked to give one, but I am able to help the information flow, to unblock the thinking, to link elements. There is my focus and that enables others to bring their great knowledge to the game and solve problems I would not have dreamt of being solved.

A key ingredient to achieving Business and IT alignment is the development of a common lexicon that all parties can use to describe and manage change.  This sounds like a fairly simple requirement, but in practice it can often prove to be difficult.  Your enterprise has this problem if you hear comments like these:

• “We aren’t all on the same page in describing the business and its needs.”
• “We have difficultly having fact based conversations about priorities.”

I’m reminded of the quote from “Cool Hand Luke” in which the Captain says to Luke “What we’ve got here is … failure to communicate.”  We do have a failure and if we can’t overcome it then all our efforts are going to be for naught.

Why do we have this problem?   Many times those of us in IT exhibit too much “inside out thinking”.  We speak of services we deliver to the business.  We speak about applications or technologies or architectural domains.  This terminology is ours and it is effective when we speak amongst ourselves, but it is ineffective when we need to communicate to business leaders.  Our customers are not going to change so in this case we are going to have to “go to the mountain” because the mountain is not going to come to us.

So what language do business leaders understand?  At Troux we have found that having a discussion with the business about “portfolios” is much more productive simply because it uses business language.  To that end we find that describing the enterprise as a set of interconnected portfolios greatly facilitates business conversations.  In fact, an “enterprise portfolio management” approach has direct analogies in to classical investment portfolio management.  Investment portfolio Management is defined as “The art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk against performance.” ¹ Likewise, at the end of the day, managing the enterprise is also about making investment decisions to manage risk and improve performance. 

Simply put business stakeholders understand what the business does and what the business does can be described in Business Capabilities.   Don’t confuse business capabilities with business processes, which are a description of “how” things are done.   And don’t think that you are speaking the language of the business when you only speak of organization structure.   Organization structure is important but as we all know it is subject to change fairly often whereas business capabilities remain a fairly stable, albeit abstract, description that establishes a commonly understood business context.  It’s worth noting that Forrester Research speaks of them as “The Rosetta Stone.” ²

Let’s consider an example — in this case we know for a fact that a set of applications need to modernized as they are implemented on obsolete, unsupported technology and have security risks.  One approach would be to propose a project to improve our technology architecture domain that will result in improved business services.  Depending on whether or not our customer understands what we said, that project may or may not easily get approved.  Now consider a different proposal: “Our business capability for customer provisioning is at risk because we have under invested in our technology portfolio.   We propose adding this project to our investment portfolio to reduce risk and improve performance of this key capability.”   This is the same proposal but will very likely yield different results, because we changed the nature of the conversation.

In practice, business capabilities can make the complex simple and enable what we at Troux call “fact based conversations.”  For a discussion of practical applications of business capabilities, attend our upcoming webinar “Speaking the Language Of The Business”.  You can register here.

[1] http://www.investopedia.com/terms/p/portfoliomanagement.asp#axzz2Jacaoaej

[1] “Business Capabilities Provide The Rosetta Stone For Business-IT Alignment”,  July 06, 2009, By Jeff Scott with Alex Cullen, Mimi An

<p><span style=”line-height: 19px;”>T</span><span style=”color: #505050; font-size: 11px; line-height: 19px;”>his is the seventh posting in our “<a title=”Blog series Sven van Dijk and Bas van Gils” href=”http://www.bizzdesign.com/blog/posts/bas-van-gils-and-sven-van-dijk”>Enterprise Architecture Roadmap for success</a>” series. In the previous posting we started to describe actionable steps that an organization needs to take in order to set up Enterprise Architecture. We described how organizations should approach Enterprise Architecture implementation as a project, with clear and confirmed ideas on scope, leadership, budget, and planning. We mentioned the establishment of a project team that will be responsible for an effective execution of the project plans. In this posting we zoom in on some of the characteristics of an Enterprise Architecture team.</span></p><p> </p><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600375-Roadmap-for-succes-establish-the-team.png” alt=”Roadmap for success: Establish an Enterprise Architecture team” title=”Roadmap for success: Establish an Enterprise Architecture team” width=”600″ height=”375″/><p class=”caption”>Roadmap for success part 7: Establish an Enterprise Architecture team</p></div><p> </p><p><span style=”color: #e3004a; font-size: 12px; letter-spacing: 1px; line-height: 15px; word-spacing: 1px;”>Building the team</span></p><p>Implementing and evolving an Enterprise Architecture function in the organization requires a whole range of roles with specific characteristics, competences, skills, and qualifications. What the most effective team for a given situation would be depends on many factors. These factors include “hard” ones, such as organization size and structure of the organization, and available resources, but also on “soft” aspects, such as culture and “political atmosphere”. These “soft” aspects are usually established through a long tradition and history, and are thus the more tough ones to change.</p><p>Building a successful team also depends on the approach and vision for enterprise architecture that an organization pursuits. In one of the first postings of this series we described two extreme approaches: top-down and bottom-up. In a top-down approach the role of enterprise architecture is more focused on supporting high-level decision making on the strategy level. In a bottom-up approach, enterprise architecture is positioned much closer to the actual operations. In this approach Enterprise Architects role is to materialize on synergy among the numerous projects (in-flight, as well as planned) by introducing standards for processes, reference architectures, and governance. In the remainder of this posting we will describe typical Enterprise Architecture team characteristics for both approaches.</p><h2><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600548-Roadmap-for-succes-build-enterprise-architecture-team.jpg” alt=”Roadmap for success: Building the team” title=”Roadmap for success: Building the team” width=”600″ height=”548″/><p class=”caption”>Building the Enterprise Architecture team</p></div></h2><h2>The top-down team</h2><p>The initiative to establish an Enterprise Architecture function that supports the organization solving the question “how should we organize ourselves” on a higher level often comes from executive levels, i.e. the CIO. The initiative is often driven by a need or feeling that the answer to this question is not yet very well understood, can be diverse and/or complex and the organization needs a multi-perspective, and creative yet structured approach to solve the puzzle. Typical situations could for example be mergers and acquisitions, or when an organization feels that more foundational changes to the business model are necessary in order to survive.</p><p>The role of enterprise architecture in this approach is to provide better insight in the organization and its high-level constituent parts in terms of people, processes/functions, and technology. Often based on high-level models, Enterprise Architecture supports the definition of the necessary change by providing impacts of suggested changes on the current organization, combines multiple perspectives such as the financial perspective,  the risk perspective, the operational perspective, the perspectives from the various areas of the business in terms of location, function, etc.</p><p>The role and position of Enterprise Architecture in this approach has a number of implications for the members of the team that is responsible for setting up the Enterprise Architecture practice. Because the scope of Enterprise Architecture in this approach is often the whole enterprise, it is an important aspect that the team has to reflect the various areas of business. For larger global organizations this means that the regions need to be represented. Or for diversified organizations, this means that the various lines of business need to be represented. Another important aspect is that members have a broad overview of the architectural landscape for their individual areas. This is why we don’t see many domain architects, such as data, application, or business process specialists on Enterprise Architecture teams in this situation. It is not easy to name typical roles in the top-down Enterprise Architecture team, but in general we could state that in the formal reporting hierarchy they are within a few steps from the CIO.</p><h2>The bottom-up team</h2><p>As we have described in one of the first postings of this series, the role and position of Enterprise Architecture in a bottom-up approach contrasts heavily with the top-down approach. In a bottom-up approach, the scope of the change is much more defined in terms of objectives and value, and also it is more clear what the architecture footprint is, i.e. the parts of the organizations on which Enterprise Architecture has an impact (provides value). Often, the Architecture Board was heavily involved in the definition of the objectives, and approach for Enterprise Architecture, now the execution of the plan will be the responsibility of the Enterprise Architecture team. In this situation the Enterprise Architecture team will often detail the approach into a working plan, and the implementation process will be governed with this working plan as starting point. The Enterprise Architecture team will frequently, often as much as every two weeks with the Architecture Board to discuss progress.</p><p>In this situation, the Enterprise Architecture team requires representation from the various functional areas within the scope of the organization. Often these areas are data, technology, security, application, etc. Important characteristics for Enterprise Architecture team members are seniority and expertise in their area, and also some history in the organization, which is important to more successfully navigate the political waters.</p><p>Although the task at hand seems much more straightforward for the bottom-up team, there are still plenty of challenges on the road. Especially the “relationship management” part of the task requires sufficient social skills. As mentioned earlier in the series, Enterprise Architecture cannot operate in isolation. Strong relationships need to be established and maintained with customers of Enterprise Architecture, in this approach e.g. mainly the project organization.</p><p></p><div class=”captionImage left” style=”width: 387px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Roadmap-for-succes-bottum-up-team.png” alt=”Roadmap for success: The top-down team” title=”Roadmap for success: The top-down team” width=”387″ height=”331″/><p class=”caption”>The top-down team</p></div><h2>Next posting</h2><p>If you’d like to know more, please contact the authors directly at <a title=”E-mail Bas van Gils” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”E-mail Sven van Dijk” href=”mailto:s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers tooling for Enterprise Architecture. It is scheduled to be posted between 25^th February and the 1^st of March. </p>

Online Ticketing for How to Fund Your Business Idea powered by Eventbrite

Permalink

| Leave a comment  »

Richard Veryard states that “Complexity is not a problem”. Let me see. Complexity is growing rapidly today. And that is as it should be.Should we not control complexity, the management of our systems and enterprises, of their issues and their…