Aggregated enterprise architecture wisdom
In September 2013, the IT University of Copenhagen opens a new Master of Science degree program in Digital Innovation and Management (Cand.it. E-Business). The program will offer three specialization tracks: Process Innovation and New Business Models Digital Governance and Enterprise Architecture Global Relations and Work Processes The second track is of course “my” track. There are …read more
Every now and then I touch the domain of interesting and relevant (e.g. Glue Governance, Enterprise Architecting Past, Future or Present, A Matter of Perspective or Don’t Panic). I want to look a bit deeper into it here, therefore as an appetizer first…
One of the benefits of knowing you’re not the smartest person in the room (any room), is that you don’t have the pressure of constantly having to prove it. Long ago I accepted the distinction of being utterly average. I used to claim I was merely…
Sinan Si Alhir is one of the more prolific tweeters that I follow, and has a perhaps-unfortunate habit of sending out sudden Twitterstreams of valuable insight that really should not be lost to the evanescence of the internet. So, in…
I explained to one of my clients recently that there is a perception of animosity between the Enterprise Architecture community and the Agile community. Both sides make assumptions about the other, often assumptions that are simply unfair. For example, many in the EA community think of “agile practices” as an opportunity to develop software without any architecture at all, while many in the agile software development community think of architecture as one of the “big design up front” guys who oppose their principles and practices. Of course, it is not difficult to find people who fit those unfair descriptions, but I’d like to point out how these two viewpoints are similar.
I believe that effective Enterprise Architecture must be approached from an agile standpoint.
First off, what does it mean to be agile? We can always look to the agile manifesto for some guidance, but more recent publications do a good job of filling in some of the details as well. I include a number of things in the notion of “being agile.” These are not just from the agile manifesto, but also Kanban and the Theory of Constraints, Systems Thinking, Six Sigma, Scrum, eXtreme Programming, and value stream analysis.
I follow the terminology of Sam Guckenheimer in calling this the “Agile Consensus.”
We have to recognize that the “agile consensus” is an approach, not a methodology. It is a way of thinking about dealing with problems. More importantly, it is a way for dealing with complex problems. The diagram below comes from Ken Schwaber (inventor of Scrum) who adapted it from Strategic Management and Organisational Dynamics, by Ralph D. Stacey.
When we look at the problems that software is being used to address, and if we look at the process of writing software itself, we have to recognize that both areas of problems typically fall into the category of “complex.” Not always. Some software is simply configured and configured simply. Some problems that software addresses are simple problems. However, most of the discussions around software development are fueled by people addressing complex problems because that is where most of the software development community works. It is the bread and butter of software development: solving complex problems in a complex way.
Enterprise architecture also deals with complex problems. EA models and information are also complex to build and manage. In this way, EA is very similar to software development. EA solves complex problems in a complex way.
In order for EA to be effective, it has to use the same mentality as agile software development.
When I speak with enterprise architects who are actually doing the job of EA, big themes quickly arise:
If this looks like the list above, that is intentional. I am trying to point out that Enterprise Architects use agile ideas, even if they often don’t use the term “agile” to convey the message.
Why use these techniques? They work for complex problems.
Can someone think of a more complex problem than helping to move an organization towards their goals?
EA addressed complex problems. Agile thinking helps them to do it.
Please join us on Tuesday, January 22 at 9:00 a.m. PT/12:00 p.m. ET/5:00 p.m. GMT for a tweet jam, moderated by Dana Gardner (@Dana_Gardner), ZDNet – Briefings Direct, that will discuss and debate the issues around big data security. Key areas that will be addressed during the discussion include: data security, privacy, compliance, security ethics and, of course, Big Data. Continue reading →
Is a market an organisation, or an enterprise? Seems to me the only valid short-answer is ‘Yes’… Can we design a market? We’d probably say ‘Yes’ there too, though perhaps with a fair few ’It depends…‘ riders attached to that answer. And…
In his presentation on Enterprise Agility at the SCiO meeting yesterday, Patrick Hoverstadt introduced the concept of Yarak.
In falconry, the word Yarak describes a trained hawk that is fit and in a proper condition for hunting. According to the Oxford Dictionary, the word entered the English language in the 19th century, perhaps from Persian yārakī ‘strength, ability’ or from Turkish yaraǧ ‘readiness’.
Patrick explained that Yarak involves a balance between two forces – motivation and strength. The falcon has to be hungry enough to want to hunt, and strong enough to hunt effectively. So the falconer has to get the balance right: too little food and the creature cannot hunt, too much food and it can’t be bothered.
When I talk to people about building organizational intelligence in their own organizations, I hear two forms of resistance. One is that the organization has so little inherent intelligence at present that the task is daunting; the other is that the bosses wouldn’t want it.
When I take examples from glamorous high-tech companies like Microsoft and Google, this can provoke a somewhat fatalist reaction. People say: This kind of intelligence may be all very well for these hi-tech birds of prey, but ordinary companies like us simply don’t have the resources or capability to do any of this stuff.
So it’s important to see examples from ordinary companies as well as from the glamorous ones. Every company has some intelligence, although it may be patchy, fragmented and inconsistent. So we need to find ways of linking and leveraging this intelligence to create a positive spiral of improvement.
As for the question of motivation, there will still be many organizations where the senior management team, perhaps lacking confidence in its own intelligence, will lack enthusiasm for developing intelligence across the rest of the organization. This may be a generation thing – the younger generation of management may be much more comfortable with new styles of management (such as “Theory Y”) as well as with social networking and other technologies.
Does this mean we have to wait for a generation, until the current bosses have shuffled off to the golf course or the Caribbean cruise? Not if the organization can start to develop intelligence in a bottom-up piecemeal fashion. In which case, what matters is the motivation and strength of the people and groups across the organization, and not just the motivation and strength of the bosses. Can we achieve some useful results without top-down support?
In his presentation on Enterprise Agility at the SCiO meeting yesterday, Patrick Hoverstadt introduced the concept of Yarak.
In falconry, the word Yarak describes a trained hawk that is fit and in a proper condition for hunting. According to the Oxford Dictionary, the word entered the English language in the 19th century, perhaps from Persian yārakī ‘strength, ability’ or from Turkish yaraǧ ‘readiness’.
Patrick explained that Yarak involves a balance between two forces – motivation and strength. The falcon has to be hungry enough to want to hunt, and strong enough to hunt effectively. So the falconer has to get the balance right: too little food and the creature cannot hunt, too much food and it can’t be bothered.
When I talk to people about building organizational intelligence in their own organizations, I hear two forms of resistance. One is that the organization has so little inherent intelligence at present that the task is daunting; the other is that the bosses wouldn’t want it.
When I take examples from glamorous high-tech companies like Microsoft and Google, this can provoke a somewhat fatalist reaction. People say: This kind of intelligence may be all very well for these hi-tech birds of prey, but ordinary companies like us simply don’t have the resources or capability to do any of this stuff.
So it’s important to see examples from ordinary companies as well as from the glamorous ones. Every company has some intelligence, although it may be patchy, fragmented and inconsistent. So we need to find ways of linking and leveraging this intelligence to create a positive spiral of improvement.
As for the question of motivation, there will still be many organizations where the senior management team, perhaps lacking confidence in its own intelligence, will lack enthusiasm for developing intelligence across the rest of the organization. This may be a generation thing – the younger generation of management may be much more comfortable with new styles of management (such as “Theory Y”) as well as with social networking and other technologies.
Does this mean we have to wait for a generation, until the current bosses have shuffled off to the golf course or the Caribbean cruise? Not if the organization can start to develop intelligence in a bottom-up piecemeal fashion. In which case, what matters is the motivation and strength of the people and groups across the organization, and not just the motivation and strength of the bosses. Can we achieve some useful results without top-down support?
Following a tweet from Tom Graves, I came acoss this article:
http://continuousdelivery.com/2013/01/on-antifragility-in-systems-and-organiz…
It resonates with a number of my earlier posts:
http://servicefab.blogspot.hk/2009/06/balancing-reliabi…
A little time back, I’m being deliberately vague which is a sin for an architect, to avoid embarrassing the presenter it’s not their fault. I had the somewhat dubious pleasure of attending a vendor briefing. The vendor in question had just been acquired by a very big software company and was on a road trip […]
<p style=”line-height: 18.99147605895996px;”><span style=”font-size: 11px; line-height: 19px;”>This is the fifth posting in our “EA Roadmap for success” series. In this posting we zoom in on the use of an </span><em style=”font-size: 11px; line-height: 19px;”>Open</em><span style=”font-size: 11px; line-height: 19px;”> approach to enterprise architecture.</span></p><p style=”line-height: 18.99147605895996px;”> </p><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600375-Enterprise-architecture-roadmap.png” alt=”Enterprise Architecture Roadmap” title=”Enterprise Architecture Roadmap” width=”600″ height=”375″/><p class=”caption”>Enterprise Architecture Roadmap</p></div><h2>Frameworks and approaches?</h2><p style=”line-height: 18.99147605895996px;”>One of the key challenges of getting started with enterprise architecture (EA) is to agree on goals for the EA practice, and subsequently to find and agree on a framework / approach / method that helps the organization to realize those goals.</p><p style=”line-height: 18.99147605895996px;”>In the early days of EA (1990’s and the early 2000’s), we saw many organizations growing their own approaches and frameworks. By working with business sponsors, architects experimented with different processes for EA, frameworks to structure EA products, modeling languages and notation and so on.</p><p style=”line-height: 18.99147605895996px;”>While this worked well in the ‘old days’, many best practices have emerged and ultimately led to the major frameworks / approaches / methods we see today: ArchiMate, TOGAF, IAF, Zachman, DYA, and so on. Some of these are ‘general purpose’, while others (e.g. MODAF/DODAF) appear to be particularly useful in a single branch.</p><h2>Build or Adopt? Open or closed?</h2><p style=”line-height: 18.99147605895996px;”>While organizations in theory face a choice of ‘build or adopt’ where it comes to frameworks, we see that many chose the latter. With all the experiences and best practices that have been developed, most organizations realize that there is little point in re-inventing the wheel all over again.</p><p style=”line-height: 18.99147605895996px;”>The question that remains, then, is this: do we adopt an open approach, or a proprietary / closed approach?</p><p style=”line-height: 18.99147605895996px;”>This question can be answered on many different levels. One could argue that “open vs closed” doesn’t really matter, as long as the selected framework does what it is supposed to do. While this may seem true at first glance, we do believe that there is a lot to be said about principally going for an open approach. The main advantages here are as follows:</p><ul><li>Know what you will get: all details about open frameworks tend to be available in the public domain.</li><li>Choose your partners: because the frameworks are in the public domain, you’ll often be able to select which vendor can help you get started – if needed at all. Along the same lines: if the vendor doesn’t deliver what was requested, switching is easier.</li><li>Get involved: perhaps most importantly, if the framework is lacking in certain areas, organizations can often join and publish their own best practices, furthering the framework for all other users.</li></ul><h2>Adopt as-is, or tailor to specific needs?</h2><p style=”line-height: 18.99147605895996px;”>To conclude this posting: there is one more choice that organizations have to make when adopting a framework, be it an open or a closed/ proprietary one: should we adopt the framework as is, or tailor it to our needs?</p><p style=”line-height: 18.99147605895996px;”> </p><div class=”captionImage left” style=”width: 348px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Enterprise-architecture-framework.png” alt=”Enterprise Architecture Framework” title=”Enterprise Architecture Framework” width=”348″ height=”400″/><p class=”caption”>Enterprise Architecture Framework</p></div><p style=”line-height: 18.99147605895996px;”>The best practice here is simple: pick and choose! Most approaches explicitly recommend users to tailor the framework to organizational needs. In TOGAF this is being done as part of the <em>preliminary phase</em>. While TOGAF recommends that certain parts <em>not</em> to be skipped, it is of course entirely up to the individual organization to decide what is useful and what is not!</p><h2>Next posting</h2><p style=”line-height: 18.99147605895996px;”>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:s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers project based implementation of EA. It is scheduled to be posted on January 29. </p>