Aggregated enterprise architecture wisdom
Continuing on the theme of Big Data, the Open Group held a panel on that topic with some of the keynote speakers along with other industry experts on this complex topic. The topics included: Big Data and the EA Perspective…
<p>This is the sixth posting in our “Enterprise Architecture Roadmap for success” series. In this posting we zoom in on the <strong>implementation and embedding</strong> of an enterprise architecture practice in an organization.</p><p> </p><div class=”captionImage left” style=”width: 600px;”><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600376-Enterprise-Architecture-Roadmap-for-success-project-based-implementation.png” alt=”Enterprise-Architecture-Roadmap-for-success-project-based-implementation” title=”Enterprise-Architecture-Roadmap-for-success-project-based-implementation” width=”600″ height=”376″/><p class=”caption”>Enterprise Architecture Project based implementation</p></div><p class=”caption”> </p></div><div class=”captionImage left” style=”width: 600px;”><h2>Enterprise Architecture is everywhere</h2><p>In one of our discussions during a client engagement we came across the following remark by one of the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span>’s in the organization: “<span style=”font-size: 10.909090995788574px;”>Enterprise Architecture </span>is about everything the organization is and does”. This remark supports our experience, and is one of the reasons that many companies struggle to effectively adopt and embed <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> in their organization. Enterprise Architecture has many stakeholders and, depending on the approach taken i.e. top-down or bottom-up, from various levels of the organization.</p><p><span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> touches on many aspects of the organization such as business and IT alignment, strategic portfolio management, project management, and risk management. Enterprise Architecture is by definition about cooperation and therefore it is impossible to operate in isolation. Successful embedding of Enterprise Architecture in the organization is typically approached as a project: with clearly defined goals, metrics, stakeholders, and appropriate governance, accountability, and with assigned responsibilities in place.</p><h2>Evolution rather than revolution</h2><p>From our experience, the road to a strong, effective, and mature <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability should be broken down into manageable pieces. We favor evolution, rather than revolution. Too many times we have seen initiatives fail due to the sky high expectations to be delivered within unrealistic time frames. <strong>Implementing </strong><span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> is a change initiative that besides processes, tools and other hard and tangible artifacts includes many “soft aspects”. These soft aspects need to be managed as such, involving mainly frequent, clear and honest communication with feedback and iteration.</p><h2>Where to start?</h2><p>The first step is to decide on the ultimate goal for the Enterprise Architecture function: where is the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> organization positioned, who are the most important customers of <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span>, and how does <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> deliver value to its customers? In the first postings of this series, the ones in the “aiming” category, we covered a number of important choices for the organization to take: are we following a bottom-up, or rather a top-down approach? How does <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> tie into strategy, project management, the corporate governance framework, and security?</p><p>Depending on the approach chosen, the next thing to do is to establish a project team that will be tasked with drafting high level plans for the <strong>implementation and embedding</strong> of the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability in the organization. The plans should describe a long-term (say 3-4 year) strategic vision for the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability, as well as a plan outlining the concrete initiatives for the short-term (say the first year).</p><p>It is one of the important tasks for the Architecture Board to provide input for the strategic vision for the architecture function, and then select the right members for the project team (see also the previous posting on “<a title=”the role of the enterprise architecture board” href=”http://blog/ea-roadmap-for-success-the-architecture-board/”>the role of the architecture board</a>”). The team should reflect the various areas and domains of the architecture, and the members should be able to look at the organization on a higher level, above the individual silos. The project team should interact with the AB frequently to make sure the efforts of the team keep aligned with the envisioned direction. In the next posting we will delve into more details around the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> project team.</p><h2>Kicking off the project</h2><p>Once the team and high level plans are in place, it is time to kick off the project. The team will take the high-level plans and preliminary decisions, such as the proposed architecture framework as a starting point, and from there make more detailed plans and start identifying and prioritizing a number of initiatives. These first initiatives should not be seen as “architecture” projects per se, but rather pertain to the question: “how do we do architecture”. Or, according to TOGAF9: “where, what, why, who, and how we do architecture”.</p><p>Aspects in this context that need to be determined and confirmed in the first phase are (not complete!):</p><ul><li>Scope</li><li>Stakeholders</li><li>Requirements</li><li>Relationship between management frameworks</li><li>Maturity assessment of required capability</li></ul><p>As mentioned before, these aspects should be considered both from a strategic, long-term perspective, as well as from a short-term perspective. This, together with the general approach for <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> chosen (e.g. bottom-up, or top-down) determines priorities and thus the order in which things should be done. For example, detailing and determining interaction of EA with other management frameworks should be done for the project management framework earlier and in more detail if a bottom-up approach is followed.</p><p>The exercise of determining scope and assessing current and desired maturity leads to a roadmap for the development of the architecture capability. With the order of activity based on various indicators such as approach chosen, prioritization, organization culture, sponsorship, etc. This road map guides the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> project team in their day-to-day activities. It is a task of the AB to make sure that the road map remains accurate and aligned with business strategy. The road map should be assessed frequently, say each half year, and necessary changes should be made accordingly.</p><h2>Using the TOGAF ADM to develop an Enterprise Architecture capability</h2><p>To conclude this posting we would like to point <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> project teams, especially in organizations that chose to adopt the TOGAF to an interesting section in the standard. In chapter 46, TOGAF describes how the ADM (Architecture Development Method) can be used as a tool to <strong>implement </strong>an Architecture Capability. In this approach, the “business architecture” of the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability involves the organizational structure of the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability, and architecture processes such as governance. The “data architecture” pertains to the meta model, and the Architecture repository that the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability uses to describe architecture, and store architectural artifacts. The “application architecture” and the “technology architecture” describe functionality and the tools (modeling tools, document management systems, etc.) that need to be deployed to support the architecture capability. Using a structured approach as suggested in the TOGAF standard helps an architecture team to draft complete and clear plans. A number of iterations of the ADM can be defined to evolve the maturity of an EA capability.</p><h2>Next posting</h2><p>If you’d like to know more, please contact the authors directly at <a title=”b.vangils@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”s.vandijk@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers the establishment of an EA team. It is scheduled to be posted between february 11th and february 15th. </p></div>
This was the key message that came out of The Open Group® Big Data Security Tweet Jam on Jan 22 at 9:00 a.m. PT, which addressed several key questions centered on Big Data and security. Here is my summary of the observations made in the context of these questions. Continue reading →
How do we make sense of the big-picture in enterprise-architecture? The really big-picture? Yep, it’s that time of year again: the lead-up to the annual Integrated EA conference, where they allow me to go somewhat off-the-wall and present the current ‘big-idea’…
With all the buzz at the Open Group Conference in Newport Beach this year around Big Data I thought I would take a small step back and write a short post that looks at the importance and the linkages of…
This is the second Open Group conference that focuses on the topic of Big Data. This is an architecture style that is getting a great deal of attention lately. With the emergence of social and the explosion of data coming…
I heard some very interesting talks today from Len Fehskens and Jeff Scott at the Open Group conference. One thing that I picked up in a meeting yesterday was the notion that TOGAF 9.1 is built on “best practices.” Today, as Jeff spoke about the transformation of a technical architect into a business architect, and as Len spoke about the challenges of communicating complex ideas, the notion of a “best practice” kept bothering me, and I cross-pollinated my concerns with the concepts that they were sharing.
I agree that the intent of the people who shared their practices with the Open Group was to provide practices that can be taught and followed. I even agree that the people on the TOGAF committees that accepted the content felt that the practices represented the best that the industry had to offer at the time. But I wonder if any of the work done in framework committees of any stripe (not to pick on the Open Group) can be held to the standard of being a “best practice.”
Are the practices in the TOGAF framework truly “best��� practices? Are these practices the best ones that the EA field has to offer?
I guess I would have to follow the EA rabbit hole and ask “what criteria do we use to judge if a practice is the best one?”
After all, when Jeff Scott talks about business architecture using capability modeling, he believes that the practice of capability modeling is the best one to use for the results he is trying to achieve. (I nearly always agree with Jeff, BTW. We sometimes differ in language, but nearly never in approach). That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice. Who are we to say? We are practitioners. While that is good, it is not enough in my mind to qualify the practice as “best.”
To be a best practice, in my opinion, a method or approach has to meet a higher bar. There has to be evidence that it is, in fact, better than just a “good practice.”
I think a best practice should have:
I wonder if we went through most of our frameworks and highlighted the text that is able to meet a higher bar, like the one I describe, how much of the text would we cover? 2%? 10%?
Is 10% coverage enough to say that a framework is based on best practices?
A strange kind of annual ritual that they did there, that subtle ‘work-to-rule’, every year that I worked at that place. Each autumn, up would come the new crop of graduates, each with their shiny new graduation-certificate and their own…
This is a transcript of a sponsored podcast discussion on Big Data analytics and its role in business processes, in conjunction with the The Open Group Conference in Newport Beach. Continue reading →
In the Australian Aboriginal culture, Dreamtime “is a complex network of knowledge, faith, and practices”. Both the word and thus cited definition invite vivid associations. The latter, with what is commonly referred to as Enterprise Architecture (EA), the former – with its current state. Note: With this I’d like to depart from further analogies as […]
How do we work on something when we don’t know what to do? Where do we start? How do we start? How do we keep going? I had some useful first-hand experience with this earlier this week. Some while back, I’d…
What do the great innovators have in common? Looking at examples from Picasso to Kepler, Art Markman calls these men expert generalists. They seem to know a lot about a wide variety of topics, and their wide knowledge base supports their creativity.
Markman identifies two personality traits that are key for expert generalists: Openness to Experience and Need for Cognition. Can we also expect to find these traits in innovative organizations?
Openness to Experience entails a willingness to explore new ideas and opportunities. Obviously many organizations prefer to stick with familiar ideas and activities, and have built-in ways of maintaining the status quo.
Need for Cognition entails a joy of learning, and a willingness to devote the time and effort necessary to master new things.
In his post on the origins of modern science, Tim Johnson compares the rival claims of magic and commerce. He points out that good science is open whereas magic is hidden and secretive; he traces the foundations of modern science to European financial practice, on the grounds that markets are social, collaborative, open, forums. But perhaps it makes more sense to see modern science as having two parents: from magic it inherits its Need for Cognition, a deep and passionate interest in explaining how things work; while from commerce it inherits its Openness to Experience, a broad fascination with the unknown. Obviously there have been individual scientists who have had more of one than the other, and some outstanding individual scientists who have excelled at both, but the collective project of science has relied on an effective combination of these two qualities.