Aggregated enterprise architecture wisdom
ABC’s Shark Tank is something that I watch on a regular basis. But I confess: I haven’t bought a single product featured on Shark Tank. I have seen very few products and ideas that I’d be interested in. Fun to watch – but there’…
ABC’s Shark Tank is something that I watch on a regular basis. But I confess: I haven’t bought a single product featured on Shark Tank. I have seen very few products and ideas that I’d be interested in. Fun to watch – but there’…
An Enterprise Architecture Cartoon!! Informative and funny.. Enjoy :-)Credit: All credit goes to FlinchStudio who made this video (I think..)
An Enterprise Architecture Cartoon!! Informative and funny.. Enjoy :-)Credit: All credit goes to FlinchStudio who made this video (I think..)
<p>This is the 12th posting of the enterprise architecture Roadmap for success blog series, before we wrap it up with an overview in the last posting. We have covered a wide range of topics so far, in this posting we zoom in on one of the most useful techniques in the field of strategic enterprise architecture planning: capability based planning.</p><div class=”captionImage leftAlone” style=”width: 337px;”><div class=”captionImage leftAlone” style=”width: 600px;”><img alt=”Capability Based Planning” class=”leftAlone” height=”375″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600375-Roadmap-for-success-capability-based-planning.png” title=”12th posting in the roadmap for succes series” width=”600″/><p class=”caption”>Part 12: Capability Based Planning</p></div></div><p><span style=”color: #e3004a; font-size: 12px; letter-spacing: 1px; line-height: 15px; word-spacing: 1px;”>Capability based planning</span></p><p><img alt=”Capability Based Planning” class=”left” height=”139″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage150139-capability-based-planning.png” title=”It may take a long time to realize the architecture” width=”150″/></p><p>There are many ways to look at architecture as we have seen in this blog series. Generally, architectures of systems (in the broadest sense of the word) are fairly high level and focus on the fundamental organization of the system as well as principles underlying this <em>fundamental</em> organization.</p><p>Especially for complex systems, it may take a long time to realize the architecture. Or, to put it in a different light, organizations may be smart and to cater for the fact that their long-term vision may change, deciding to take it one step at a time, allowing for the vision / architecture to change. This also takes into account the fact that organizations already have certain capabilities that they may wish / need to develop further in an incremental fashion. This is where Capability Based Planning kicks in.</p><h2>Capability Based Planning – the TOGAF™ way</h2><p>Many definitions for capabilities (and frameworks around capabilities) have been proposed and used in practice. In this post we zoom in on the TOGAF-framework which is fairly well aligned with other capability frameworks. The TOGAF-standard has two definitions for the term Capability, which can loosely be paraphrased with the statement “A capability is an ability that an organization, person, or system possesses”. Capabilities are typically ‘horizontal’ in the sense that they span many lines of business as is illustrated by the figure below (from <a href=”http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html” target=”_blank”>Chapter 32</a> of the TOGAF standard), but that is not always the case.</p><p><img alt=”TOGAF and Capability Based Planning” class=”leftAlone” height=”333″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600333-TOGAF-framework.png” title=”The TOGAF-standard has two definitions for the term Capability” width=”600″/></p><p class=”caption”>Two capability definitions in TOGAF</p><p>The idea is that an organization’s capability may be at a certain ‘level’ at some point in time. In order to further that capability – conform the Architecture Development Method – a new architecture is developed (using e.g. ArchiMate), which is fleshed out in more detail in a solution model (e.g. ArchiMate, UML, BPMN) before it is actually implemented:</p><p><img alt=”Capability, Architecture, Solution model” class=”leftAlone” height=”193″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600193-Screen-Shot-2013-04-26-at-11.32.44-.png” title=”a new architecture is developed (using e.g. ArchiMate), which is fleshed out in more detail in a solution model (e.g. ArchiMate, UML, BPMN) ” width=”600″/></p><p>Another important aspect of capabilities lies in the fact that they may have different ‘dimensions’. For example, <a href=”http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html” target=”_blank”>Chapter 32</a> of the TOGAF standard lists a people dimension, process dimension, and material dimensions for a given capability. In other words, when planning the next increment for our ability (i.e., the goal we want to achieve for this increment in the next ADM cycle), we should consider the ramifications for each of these dimensions.</p><h2>Modeling support</h2><p>Given the integration between ArchiMate® and TOGAF™, we feel that capability based planning also deserves proper modeling support. We are working on a simple meta-model to support capability based planning, the core of which looks like this:</p><p><br/><img alt=”Capability based planning. A meta model” class=”leftAlone” height=”301″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/core-modeling-ArchiMate-TOGAF.png” title=”meta-model to support capability based planning” width=”422″/></p><p>This sample shows that capabilities may have one or more dimensions, and are realized by one of more increments, indicative of the different points in time. These increments are still conceptual in nature, and indicate points in time. Each increment may be realized by an architecture, expressed as a set of core concepts (<a href=”http://www.bizzdesign.com/blog/archimate-core-overview/” target=”_blank”>see our series on ArchiMate</a>). Using this simple meta-model we can create the following view:</p><p><img alt=”Capability with 5 different dimensions” class=”leftAlone” height=”299″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage500299-core-concepts-meta-model-ArchiMate-TOGAF.png” title=”Each increment may be realized by an architecture, expressed as a set of core concepts” width=”500″/></p><p>Here we see a capability with 5 different dimensions. In each of the four increments, the capability has a certain <em>value</em> that indicates ‘how good we are doing with respect to this capability’. As the analysis of this diagram may be hard, we propose a simple radar view as follows:</p><p><img alt=”radar view of capability” class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/customer-dimension-capability-increments.png” title=”Capability radar view” width=”350″/></p><h2>Use in practice</h2><p>In our experience, Capability Based Planning as a technique can be used in a many different settings. The main benefit of this approach lies in the combination of easy communication (capability is a term that management tends to understand well) while still allows for formal modeling and analysis. We have used it successfully in helping one of our clients in furthering their data management practice, linking the technique of capability based planning with the DAMA DMBOK framework. The DMBOK framework decomposes the data management capability into several sub capabilities such as data governance, master data management, Business Intelligence and so on. It also proposes to consider each capability from different dimensions which may lead to an assessment such as:</p><p><img alt=”Capability assessment” class=”leftAlone” height=”270″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage450270-DAMA-DMBOK-framework.png” title=”such diagrams communicate well and provide a solid basis for further analysis and realization” width=”450″/></p><p>Indeed, such diagrams communicate well and provide a solid basis for further analysis and realization (which steps will we take? When? What is the architecture that goes with each of these steps? How does this translate to projects that take us to the next level?).</p><h2>Next posting</h2><p>If you’d like to know more, please contact the authors directly at <a href=”mailto:b.vangils@bizzdesign.com” target=”_blank”>b.vangils@bizzdesign.com</a> / <a href=”mailto:s.vandijk@bizzdesign.com” target=”_blank”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next wraps up the series! It is scheduled to between 6th and 10th of May.</p><p> </p>
As you’ve read over past couple of years, we’ve started investing in a hybrid Angel/VC model. Lots of risk, lots of upside, and lots of fun new things to learn. Applying Capability Driven Methods to management from the start has been both f…
As you’ve read over past couple of years, we’ve started investing in a hybrid Angel/VC model. Lots of risk, lots of upside, and lots of fun new things to learn. Applying Capability Driven Methods to management from the start has been both f…
Some people question my use of the word “emerging” to categorize technologies such as social, mobile, cloud, analytics, sensors and others. They argue that these technologies are already here and aren’t emerging anymore. Some suggest using “disruptive” to describe them instead. Now is a good time to distinguish between these two labels and make sure that we are using each to help us better understand technology’s impact to our businesses. Emerging means to come into […]
If you liked this, you might also like:
When was the last time you found yourself on a project that didn’t involve some degree of file transmission? No, that one doesn’t count… Ok, so maybe you occasionally have a solution that doesn’t require any file delivery but every architect worth his weight in .csv files is going to come across this task at […]
In part 4 of “Memoirs of an Enterprise Architect” I discussed the rules around defining an application as well as the 6 keys to successful Application Portfolio Management. In Part 5, I will discuss integrating with a Configuration Manage…
Alignment though essentially means transforming the enterprise (technology for instance) to perform what the business needs on an operational, tactical and strategic scale.
As I’m about to complete my share of a longer engagement on using Lean principles to improve the processes at an online services firm, it occurred to me that the efforts we undertook to properly embed Architecture practices into their Scrum process were novel. I haven’t seen much written about how to do this in practice, and I imagine others may benefit from understanding the key connection points as well. Hence this post.
First off, let me be clear: Agile software development practices are not at all averse to software architecture. But let’s be clear about what I mean by software architecture. In an agile team, most decisions are left to the team itself. The team has a fairly short period of time to add a very narrow feature (described as a user story) to a working base of code and demonstrate that the story works. The notion of taking a couple of months and detailing out a document full of diagrams that explains the architecture of the system: pretty silly.
The value of software architecture is that key decisions are made about the core infrastructure of the system itself: where will generalizations lie? Will a layered paradigm be used, and if so, what are the responsibilities of each layer? What modules will exist in each layer and why will they be created? How will the responsibilities of the system be divided up among the layers and components? How will the modules be deployed at scale? How will information flow among the modules and between the system and those around it?
The way these questions are answered will indicate what the architecture of the system is. There are many choices here, and the “correctness” of any choice is a balance between competing demands: simplicity, security, cost, flexibility, availability, reliability, usability, correctness, and many more. (These are called “System Quality Attributes”). Balancing between the system quality attributes takes thought and careful planning.
So when does this happen in an agile process?
Let’s consider the architect’s thinking process a little. In fact, let’s break the software architecture process into layers, so that we can divide up the architectural responsibility a little. You have three layers of software architectural accountabilities. (Repeat: I’m talking about Software Architecture, not Enterprise Architecture. Please don’t be confused. Nothing in this post is specific to the practice of Enterprise Architecture). All this is illustrated in the diagram below. (Click on the diagram to get something a little more readable.
At the top, you have the Aligning processes of software architecture. These processes consider the higher levels of enterprise architecture (specifically the business and information architecture) to create To-Be Software Models of the entire (or relevant) software ecosystem. If you’ve ever seen a wall chart illustrating two dozen or more software systems with connectors illustrating things like flow of data or dependencies, you’ve seen a model of the type I’m referring to. Creating and updating these kinds of diagrams is a quarterly or semi-annual process and reflects the gradual changes in the strategy of the enterprise.
In the middle, you have the Balancing processes of software architecture. These processes consider the needs of a single system but only from the level of deciding why the software will be divided up into modules, layers, and components, how that division of responsibility will occur, and what the resulting system will look like when deployed in specific technologies in a specific environment. All of this can be conveyed in a fairly short document that is rich in diagrams with a small amount of text explaining the choices. This occurs once when a system is moving forward, and the software architecture can be developed alongside the first couple of sprints as input to the third and subsequent sprints.
At the bottom, you have the Realization processes of software architecture. This is where the architecture becomes software, and this is where decisions are made about the choice of specific design patterns, the appropriate level of configurability vs. simplicity, and the ability to demonstrate whether the actual intent of the architecture occurs in practice. In agile, this layer occurs within the team itself. The software architect can offer advice about what patterns to use, but it is up to the team to realize that advice and/or decide not to implement it. The team will very likely implement the software architecture as described, but may choose to improve upon it.
What does the process look like
There are many visualizations of scrum running around. Some are described in books, others in papers or blog posts. Most share some common elements. There is a product backlog that, through the magic of sprint planning, the team extracts a subset for the sprint. This becomes the sprint backlog. The illustrations then tend to show the various rhythms of Sprint as cycles (sprint cycles and daily cycles), ending with a demonstration and retrospective.
In order to illustrate and train a team on all elements, including the business analysis elements, we chose to be a bit more explicit about the steps PRIOR to sprint planning, including the processes of creating and improving the stories prior to the start of a sprint. (as above, click on the image to enlarge it).
Astute observers will notice that we added a step that we are calling “pre-sprint story review.” This is a meeting that occurs one week prior to the start of a sprint. It is called by the product owner and he or she invites “senior chickens” (architects, user experience leads, development and test leads, and any other “non-team” members that want a say in the sprint.
In that week prior to sprint planning, those folks, working with the product owner, can improve the stories, add constraints, refine the description and acceptance criteria. And here’s where the architects get to play. Architects fulfilling the role of “Balancing” in the model above will have (or can create) an outline document describing the architecture of the software system, and can “link” that document to the SPECIFIC STORIES that are impacted by that design.
(Note: assuming you are using a tool like Microsoft’s Team Foundation Server, that fully enables Scrum in multiple forms, this is a nearly trivial activity since a document can be easily linked to any story. Enough advertising.)
So is an architect a chicken or a pig? Answer: depends on what “layer” the architecture is at. The top two layers are chickens. The third layer, realization, is done by the team itself. The person on the team may or may not have the title of “designer”. (I’d prefer that they did not, but that’s just because I believe that ALL team members should be trained to fulfill that role. In reality, the skill may not be wide spread among team members). Therefore, the third layer is done by the pigs.
I hope this provides some insight into how a team can embed software architecture into their scrum cycles. As always, I’m interested in any feedback you may wish to share.