Search Results for: business model

Four principles for a sane society

by

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’…

Rumination on the concept of “best practice”

by

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:

  • Some measurement (evidence) that demonstrates that it is an effective practice, and that the measurement shows that it is at least as effective as other practices,
  • A clear understanding of the results of the practice and the context in which it is to be performed (think “Pattern Language” criteria),
  • Some analysis to show that it meets other criteria like broad applicability and simplicity, and
  • We should demonstrate the ability for that practice to be understood and performed by people who are currently in the role (e.g. can we teach it, and if we teach it, can others do it?).

 

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?

The over-certainties of certification

by

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…

drEAmtime

by

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 […]

The Antifragile Enterprise: Complexity Exists, but Let’s Not Overcomplicate it or IT.

by

The Enterprise is a complex system.  I have accepted that fact.   I think many of us in the enterprise architecture profession have also accepted this fact as well, or at least I hope we have.   But then again there is natural response to things in which we do in order to address “complexity.”  There is a tendancy to…

EA is Strategic Planning

by

Enterprise Architecture quite simply is all about Strategic Planning. It helps enterprises shape their future structure and dynamics in the face of the changing environment in which they do business. Its purpose is to understand the ends and means that form the strategies needed. How does an enterprise react to events that do and will […]

All Effective Enterprise Architects Are Agile

by

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.

  • A focus on performing high-value activities, and removing low-value activities.
  • A focus on empowering the people who make things to make decisions about how those things should be made.
  • A focus on developing small increments of actual value on a frequent basis and getting direct feedback on them.
  • A focus on making sure that one thing is “done” before moving to the next, so that we reduce “debt” as we go.
  • A focus on modern practices that remove ‘deployment impedance’ like test driven development and continuous integration.

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.

image

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:

  • do the work that is highly valuable and don’t do the work that the business doesn’t value
  • build consensus where it actually lives, not where the “people from above” believe that it does
  • deliver value quickly and in increments that your stakeholders understand
  • leave your repository in a good state of completeness with all the data that others need to use it
  • build in the deliverable artifacts into the business processes that need it, so that you get immediate feedback

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.

Enterprise Architecture Roadmap for success: Adopting an open approach to Enterprise Architecture

by

<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>

Categories Uncategorized