Category Archives: Enterprise Architecture

What do Reuse Engineers do?

Reuse engineering is an important, and arguably advanced, aspect of the Disciplined Agile framework.  The challenge is that reuse engineering requires significant discipline and organizational maturity to be successful, hence we tend to run into far more talk about reuse than action.  Having said that, many organizations have been very successful with reuse.  The following diagram overviews the internal workflow of a reuse engineering team, capturing key activities (the blue bubbles) that the team performs.  This blog posting explores what reuse engineers do in practice.

Internal workflow of a reuse engineering team

Let’s work through the primary activities performed by reuse engineers:

  1. Guide teams in reuse.  An important activity for reuse engineers is to provide guidance to delivery teams regarding what is available for reuse, how to go about accessing and applying the reusable artifacts, and educating teams in why reuse is important to both the team and to your organization.   Very often a team’s architecture owner will collaborate with the reuse engineering team to bring a reuse engineer into the team at the right time.
  2. Obtain assets.  Reuse engineers will obtain reusable assets from a variety of sources, including from the marketplace and from internal delivery teams.  Based on the various organizational roadmaps, and the needs of the delivery teams that they’re working with, the reuse engineering team will often work with delivery teams to identify and obtain the appropriate assets from the marketplace.  The goal is to find assets that fit the needs of individual teams in a way that aligns with the direction of the organization.  Furthermore, reuse engineers tend to monitor what delivery teams are doing, often by working closely with the organization’s enterprise architecture team and the architecture owners on delivery teams, to help them identify potentially reusable assets.  When a team believes it has built something that is potentially reusable by others, or when the reuse engineers believe they have done so, then the reuse engineers will work with the team to understand and harvest that asset.
  3. Publish reusable assets.  An asset is potentially reusable when it is of high quality, it is appropriately documented, one or more examples exist of how to use it, and it is findable by others.  The publishing process ensures that all of these criteria are true.  The reuse engineers will do the work to publish the asset, refactoring and documenting it as needed and harvesting any usage examples if available (and creating some when not).  After doing so, they will save the asset and its related supporting artifacts into your organization’s reuse repository, announcing the availability of the new asset after doing so. Note that reuse repositories, also called asset managers, have fallen out of favor in the past few years due to the complexity of the available products on the market and the propensity of organizations to use products like Git or Microsoft SharePoint as repositories.
  4. Configure asset for specific use.  Reuse engineers will often work with a team to help them to configure an asset for specific use.  The goal is to make it as easy as possible for others to reuse existing assets, thereby increasing the chance of rate of successful reuse within your organization.
  5. Integrate reusable assets into a solution.  Reuse engineers will often work with delivery teams to integrate a reusable asset into their solution, once again to make it as easy as possible for teams to reuse existing assets.  Interestingly, an important aspect of harvesting an asset for reuse is to help the source team to integrate the improved version of the asset back into their solution.  This helps to increase the likelihood that teams will offer up potential assets for harvesting and publishing.
  6. Evolve reusable assets.  Assets need to evolve over time to reflect changing requirements and implementation technologies.  The implication is that the owners of the assets, often the reuse engineering team, will need to evolve their assets, publish new versions, and deprecate old versions.  This is work that must be funded and supported properly.

If your organization is serious about reuse engineering then they will explicitly fund a reuse engineering team and enable them to work in the manner that we’ve described here.  For more information, you will find the article Reuse Engineering to be of value.

Rolling Wave Planning in Disciplined Agile

Wave

The basic idea with rolling wave planning is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

Rolling wave planning is implemented in several places of the DA framework. First, as you can see in Figure 1 below, it is an option of the Level of Detail decision point of the Develop Initial Release Plan process goal. A rolling wave approach to release planning has the advantages of more accurate and flexible planning although can be a bit disconcerting to traditional managers who are used to annual planning strategies.

Figure 1. The Develop Initial Release Plan goal diagram.

Develop Initial Release Plan

 

The Portfolio Management process blade supports rolling wave budgeting as an option for its Manage the Budget decision point. This is depicted in Figure 2. The advantages are greater flexibility and greater likelihood of investing your IT funding more effectively, albeit at the loss of the false predictability provided by an annual budgeting strategy.

Figure 2. The goal diagram for the Portfolio Management process blade.

Disciplined Agile Portfolio Management

 

The Program Management process blade supports rolling wave planning of a program itself, as you seen in Figure 3. Planning and coordination are critical on a large program, and rolling wave planning offers the advantages greater flexibility, the ability to think important cross-team issues through, and the ability to react to changing stakeholder needs. The primary disadvantage is that it can be disconcerting for traditionalists who are used to thinking every thing through from the beginning.

Figure 3. The goal diagram for the Program Management process blade.

Disciplined Agile Program Management

 

As you can see in Figure 4, rolling wave strategies can be applied in Product Management to evolve the business vision/roadmap. A continuous, rolling wave approach is critical to your success because the market place changes so quickly – these days, few organizations can tolerate an annual approach to business planning and in the case of companies with external customers an ad-hoc approach can prove to be too unpredictable for them.

Figure 4. The goal diagram for the Product Management process blade.

Disciplined Agile Product Management

 

Previously we saw that rolling wave strategies can be applied to evolve your technology roadmap, as indicated in the goal diagram for Enterprise Architecture in Figure 5. The advantages of this approach are that your roadmap evolved in sync with both changes in technology and with your organization’s rate of experimentation and learning. The main disadvantage is that your technology roadmap is effectively a moving target.

Figure 5. The goal diagram for the Enterprise Architecture process blade.

Disciplined Agile Enterprise Architecture

As you can see, rolling wave strategies are an integral part of the Disciplined Agile (DA) framework. In fact, in most situations they prove to be the most effective and flexible strategies available to you. The advantages of rolling wave planning tend to greatly outweigh the disadvantages. More on this next time.

Rolling Wave Planning for Technology Roadmaps

Rolling wave

For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) framework, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few. This article explores how to apply rolling wave planning in a pragmatic manner to technology roadmaps.

An important aspect of your enterprise architecture efforts is to provide architectural guidance, both business and technical guidance, to your organization. One of the key artifacts that enterprise architects will create is a technology roadmap that, as the name suggests, provides guidance as to the proper application of technologies within your organization. This roadmap will often supplement any “as is” and “to be” models that the enterprise architects create.

Technology roadmaps are often evolved following a rolling wave planning approach. Figure 1 depicts an example of a technology roadmap, the goal of which is to  give technical direction to solution delivery teams so as to provide safety rails around technical experimentation.

Figure 1. A technology roadmap in September 2016.

Rolling wave technology roadmap

 

Notice how this roadmap addresses several categories of technical issues:

  1. Planned upgrades. Development teams need to know what aspects of your infrastructure will be evolving and when. Upgrades that are soon to occur have been assigned dates as these changes are very likely going to impact several development teams.
  2. Experiments. From an agile point of view the most interesting thing is the list of experiments that the enterprise architects are overseeing. These experiments usually occur within one or more of the development teams underway in this company. In this case the EAs are coordinating and guiding the experiments, ensuring that the teams focus on experiments that reflect the overall direction of the organization. In some cases you may choose to have an explicit proof of concept (PoC) project to validate a new technology, a common approach for major infrastructure components or expensive packages. Either way, by planning for explicit experimentation you bring greater discipline to your learning and architectural evolution efforts.
  3. Reusable infrastructure. This company has a reuse engineering effort underway where common architectural components, in this case microservices, are built and then made available to development teams. Once again, the closer to being released the reusable components are the more likely it is to have a target date for their release.
  4. Retirements. An aspect of technology roadmaps that are often forgotten are the plan to retire existing systems and infrastructure components. An important part of paying down technical debt within organizations is the consolidation of your IT infrastructure – reducing the number of technologies that you’re using, removing redundant systems, and so on. Such retirement efforts can take months and even years. We see in Figure 1 that SQLServer is currently being retired from service, development teams are migrating to approved database technologies, and that it is slated to be completed by February 5th. In this case the enterprise license for SQLServer ends in April 2017 so they’re hoping to be completely off of it two months before that.

 

What Should the Planning Horizon Be?

Technology roadmapping tends to have between a six month and three year planning horizon depending on what is being planned for. For example, experiments are typically planned out a few months in advance as they are often driven by the needs of development teams. Major upgrades are typically planned on a horizon of six months to a year as this reflects the rate of change of many technologies. Retirements might typically planned for years in advance, particularly when the retirement could impact multiple systems.

 

How to Capture Technology Roadmaps

Technology roadmaps are typically captured in text format as you see in Figure 1 above, although a timeline format (as we say with product roadmaps) are often used for executive presentations.

This sort of planning is only one of several things that your enterprise architecture team will do of course. In addition to actively guiding development teams and working with senior stakeholders, the enterprise architects are also maintaining current and to-be models and are hopefully producing code examples for how to work with new architectural components.

Introduction to Rolling Wave Planning

Rolling wave

For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) framework, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few.  This blog overviews this important practice.

The basic idea is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

In Figure 1 below you see an overview of how rolling wave planning works and in Figure 2 an example of how a Disciplined Agile Delivery (DAD) team applies it for release planning. Upcoming work is planned in detail, the planning unit “X” is one month in the case of the delivery team. In order to do their work they need detailed user stories and supporting artifacts such as acceptance criteria and supporting models such as user interface (UI) sketches or data source analysis. They have this information for the work that they are doing right now as well as about one month’s of upcoming work. They don’t yet need details for work that is several months away in time. In this case for work that is two to three months in the future they only have user stories developed and work that is four to six months away epics. Work in what the team considers to be the distant future, in this case six or more months away, is described in very high-level terms such as epics or solution capabilities.

Figure 1. Rolling wave planning overview.

Rolling wave planning overview

Figure 2. Rolling wave release planning on a solution delivery team.

Rolling wave release planning overview

Part of the work that the team is doing right now is to keep their plan up to date. For example, if they are working in two week iterations they will pull two weeks of work into the team. During the current iteration they will pull about two weeks of user stories from the near term category (the yellow box in Figure 2) into the very near term (the green box). They may also bring upcoming work into the near term category at this point too.

Rolling wave planning has its source in iterative software development such as the Rational Unified Process (RUP). It is a strategy that is commonly applied by agile software teams and the Project Management Institute (PMI)’s Project Management Book of Knowledge (PMBoK) supports it.

In future blog postings in this series we will work through examples of applying rolling wave planning in practice.

Enterprise Architecture Q&A

Puzzled

On May 17 2016 I gave a webinar entitled Agile Enterprise Architecture: Disciplined and Pragmatic Strategies (at this link you can watch a recording and download a PDF of the slides). During the webinar I received many questions, some of which we had time to answer but some which we did not.  Regardless, here are all of the questions and my answers.  I’ve organized them into the following topics:

  1. Long vs. Short Term
  2. Deferring Commitment
  3. Transitioning to Agile EA
  4. General

 

1. Long vs. Short Term

What about longer term? How do you see the role of EA on portfolio creation?  As you can see in Disciplined Agile’s Enterprise Architecture process blade one of the primary tasks of the EA activity is to consider the longer term. The enterprise architects will collaborate to do so, and will help bring their vision to their stakeholders in various ways.  As you can see in the workflow, the EAs will interact with the Portfolio Management effort (and many others).

How do you balance the needs of today vs. the needs of tomorrow? Would you wait for business to identify it as a priority, which may be too late… or look to get ahead of the curve and build something that can scale for anticipated growth? Experienced enterprise architects will definitely think about the long term needs of the organization. Disciplined Agile EAs will do so but will wait to act to the most appropriate time to do so.

 

2. Deferring Commitment

Can you point us to some places to read more about deferred commit? Deferring commitment to the last most responsible moment is a concept that comes from lean software development. I recommend the writings of Mary and Tom Poppendieck as well as the book SDLC 3 by Mark Kennaley.

If we defer commitment, how about if we need infrastructure, procurement and so on to implement that architecture? This deferring will delay the entire implementation? No. The advice is to defer commitment to the last most responsible moment.  You need to understand the needs of your stakeholders, which in Disciplined Agile include a wide range of people, and then act accordingly. The problem is that traditionalists will act too early and thus add unnecessary risk.

A good observation from Valentin Tudor-Mocanu is that to be able to defer decisions we need a design that separates the concerns (adaptive design).

 

3. Transitioning to Agile EA

Is there a strategy to change the mindset of enterprise architects on a large organization?  Yes. It first begins with education.  We offer a one-day workshop called Agile Enterprise Architecture: Disciplined and Pragmatic Strategies that does a very good job of working through the fundamentals.  The next step is coaching of the EA team themselves, and of the teams that they interact with, to help them gain the mindset and habits required to work in a more effective agile/lean manner.  We also provide such coaching services.

One specific question related to a service or consulting organization: One of the specific requirements for us to is to deliver architecture as a deliverable. How can agile can help us?  Can we apply sprints there?  Can we apply any architecture principles? I’ll assume you meant an architecture model as a deliverable. The answer is yes, you can easily create an architecture model in an agile manner. I highly suggest that you visit the Agile Modeling site and read the advice about agile architecture strategies and to agile documentation strategies.

 

4. General

Can you talk about metrics in agile EA and Architecture in general?  In the Disciplined Agile framework we suggest that you adopt a lightweight Goal-Question-Metric (GQM) approach to your metrics strategy. The fundamental idea behind GQM is that you first identify a goal that you would like to achieve, a set of questions whose answers are pertinent to determining how well you’re achieving that goal, and then the metric(s) that could help you to answer each question. In short, the metrics that you gather will vary based on your need.

Given that Feedback cycle plays an important role, why does DAD say “Reduce feedback cycle”? Is there a pre-defined cycle frequency?  You should find the blog posting Reducing the feedback cycle requires discipline to be an interesting read.

Some forms of architecture (UX/UI) need a different cadence than the delivery team follows. What is your recommendation for handling this… UX research, etc? I disagree with your premise. I’ve heard this claim in the past and it’s never held water with me.  About 10 years ago I wrote an article entitled Introduction to Agile Usability that overviews how UX activities can appear in the agile lifecycle.  The Lean UX community has clearly gone further than what I originally wrote so you might want to go poking around on the web a bit.

When the business case says “many years before payback”, doesn’t that usually mean that the business case is missing some important elements? (or that the org is really small) ?  My experience is that the business case is usually crap in these situations. There in fact a few things in the software world that may have a multi-year payback period, operating systems come to mind, but they are more the exception to the rule.  The problem with multi-year payback schemes in the software world is that the ecosystem changes so quickly.  During the several years it takes for payback your needs change, there are new options on the market, your organization structure and direction may change, and so on.

I realize I’m asking a history question here, but regarding deferring commitment, a superb method for this that I have often used in the past comes from RUP: architecture mechanisms. (I should know this but) Is this in DAD?  If you read the Enterprise Architecture process blade article you will see that it supports several strategies for capturing and communicating EA ideas such as reference architectures, models, architectural runways, interfaces, and many others. You might also find the Reuse Engineering process blade to be of interest.

 

What can you reuse on agile software teams?

An important philosophy for succeeding at reuse engineering in the information technology (IT) space is to understand that you have more than one option at your disposal.  You can reuse source code, components, development artifacts, patterns, and templates.   The following diagram summarizes the types, or categories, of reuse available to you.  The left-hand arrow indicates the relative effectiveness of each category – pattern reuse is generally more productive than artifact and framework reuse for example.  Similarly, the right hand arrow indicates the relative difficulty of succeeding at each type of reuse.  Code and template reuse are relatively easy to achieve because you simply need to find the asset and work with it.  Other forms of reuse become hard to achieve; with framework reuse you need to learn the frameworks, with pattern reuse you must learn when to (and when not to) apply various patterns, and with architected reuse you need an effective approach to enterprise architecture in place.

Reuse types

The reuse categories are:

  • Architected Reuse.  The identification, development, and support of large-scale, reusable assets via enterprise architecture.  Your enterprise architecture may define reusable domain components, collections of related domain/business classes that work together to support a cohesive set of responsibilities, or service domains which bundle a cohesive collection of services together.
  • Pattern Reuse. The use of documented approaches to solving common problems within a specified context.  With pattern reuse you’re not reusing code, instead you are reusing the thinking that goes behind the code.  Patterns can be a multiple levels – analysis, design, and architecture are the most common.  Ward Cunningham’s site is a useful source of patterns on the web.
  • Framework Reuse. The use of collections of classes that together implement the basic functionality of a common technical or business domain.  Horizontal frameworks, such as a security framework or user interface frameworks such as the Kendo or QuickUI.   Vertical frameworks, such as a financial services framework, are common in some domains.
  • Artifact Reuse. The use of previously created development artifacts – use cases, standards documents, domain-specific models, procedures and guidelines, and even other applications such as a commercial off the shelf (COTS) package – to give you a kick start on a new project.  Sometimes you take the artifact as is and other times you simply use it as an example to give you an idea about how to proceed.
  • Component Reuse.  The use of pre-built, fully encapsulated “components” in the development of your solution. In this case a component is self sufficient and encapsulates only one concept.  Component reuse differs from code reuse in that developers don’t have access to the source code.
  • Template Reuse. This is the practice of using a common set of layouts for development artifacts such as vision documents, training slide decks, or system overview wiki pages within your organization.
  • Code Reuse. The reuse of source code within sections of an application and potentially across multiple applications.  At its best code reuse is accomplished through the sharing of common classes and/or collections of functions and procedures.  At its worst code reuse is accomplished by copying, pasting, and then modifying existing code which adds to your organization’s technical debt and can potentially result in negative overall value.

You can address these reuse categories simultaneously.  Framework reuse often locks you into the architecture of that framework, as well as the standards and guidelines used by the framework, but you can still take advantages of the other approaches to reuse in combination with framework reuse.  Artifact and component reuse are the easiest places to start, with a little bit of research you can find reusable items quickly.  However, if your organization doesn’t have a common development process that it follows you may get little benefit from templates.  Pattern reuse is typically the domain of developers with good modeling skills and your enterprise architects should be publishing and providing pattern-oriented guidance to them.

It is important to note that although the diagram indicates that pattern reuse is generally more effective than artifact reuse you may discover that within your organization the opposite holds true.  This may occur because you have a comprehensive collection of reusable artifacts in place, because your organization culture is conducive to artifact reuse, or simply because your developers have little experience with patterns.

How Enterprise Architecture Enables Agile Software Development

Layered Architecture

Enterprise architecture, when performed in a disciplined agile manner, is an important enabler of agile software delivery.  This is true for several reasons:

  1. Common architecture enables agile teams to focus on value creation.  A common enterprise architecture enables reuse across delivery teams.  When agile teams have high-quality assets – such as micro-services, legacy data sources, and frameworks – available to reuse they are able to focus on creating new value for their stakeholders and not on reinventing new versions of existing assets.
  2. Common technical guidance enables greater consistency between teams.  When team follow effective, common conventions it results in greater quality.   This makes it easier to learn about assets that are new to them, in particular existing source code, and to evolve those assets as needed.  Greater consistency also makes it easier for people to move between teams because it will be easier for them to come up to speed on what the new team is doing and to share their skills with those team members.
  3. Agile architectures enable disaggregation.  When your solutions are built from loosely coupled, highly cohesive components it is easier to spread development work across smaller teams.  This reduces overall risk and organizational complexity, which in turn reduces time-to-delivery.  It also allows agile teams to focus on what they’re building instead of coordinating with other teams or mocking out the (undelivered) work of other teams.
  4. Common infrastructure enables continuous delivery.  When there is a common technical infrastructure to IT delivery teams to deploy into it is easier to deploy.  The easier it is to deploy, the more often it makes sense to deploy.
  5. Enterprise architecture scales agile.  A disciplined agile approach to enterprise architecture enables organizations to scale agile strategies “horizontally” across their entire IT department.

The Disciplined Agile Delivery (DAD) 1.x framework purposefully included the philosophy of enterprise awareness, the need for agile delivery teams to look beyond their immediate needs and consider the long-term needs of their organization.  A common example of this is to work closely with your organization’s enterprise architects.  The Disciplined Agile 2.0 framework, which we are incrementally publishing here at DisciplinedAgileDelivery.com, explicitly addresses Enterprise Architecture so that organizations may see how it fits into the overall strategy to build an agile organization.

Disciplined Agile Enterprise Architecture: Workflow

In this blog posting, the latest in our ongoing disciplined agile enterprise architecture (EA) series,  overviews the workflow of a disciplined agile EA team.  We look at two views of this workflow, from within the team and with other IT teams.

Workflow Within the Team

The workflow within a disciplined agile enterprise architecture team is depicted in the following diagram.

Agile Enterprise Architecture Process

There are four major activities:

  1. Envision initial architecture.  The enterprise architects will spend several days developing initial, high-level models of the enterprise architecture.  This will be a face-to-face, initial architecture envisioning session where the scope is the entire organization, not just a single IT solution.  Ideally this is done in an agile modelling room so as to streamline the communication and collaborative modelling efforts.  Such a room is large with lots of whiteboard space, enabling the team to work on several models in parallel (each of which has its own section of wall space).  The primary purpose of this session is for the EA team to develop a common understanding, at least a high level, of the current state of the enterprise architecture and a vision for how the team would like to see it evolve.  Secondary outcomes include creating some initial artifacts which the enterprise architects will evolve over time, (potentially) meeting one another for the first time, and building bonds between the team members.  Potential challenges to this activity include getting an agile modeling room (you may have to convert an existing room, or accept lower productivity if you can’t get access to such a room) and the logistics of getting the right people together at the same time.
  2. Collaborate with business stakeholders.  On a regular basis enterprise architects work with business stakeholders to understand their needs, work with them to envision the future, and help educate them on the possibilities and constraints of technology.  This collaboration may be in the form of working sessions, presentations, or one-on-one conversations.  These sessions occur as needed and at times it can be difficult to gain access to stakeholders as they are often very busy people.
  3. Collaborate with IT stakeholders.  Disciplined agile EAs will spend the majority of their time, 80 to 90% of it typically, working as members of IT delivery teams.  By doing this they bring their knowledge, vision, and skills to the team in a pragmatic, hands-on manner. On Disciplined Agile Delivery (DAD) teams they will often take on the role of architecture owner (AO).  Enterprise architects will also work with other IT stakeholders, including operations engineers, support staff, the data management team and so on so as to understand their needs.  More on this in the next section.
  4. Evolve architecture assets.  The enterprise architecture team, or at least the portion of the team who is currently available, will meet on a regular basis to evolve the enterprise architecture assets based on their learnings.  A common pattern we’ve seen it for the team to meet every Friday afternoon for two hours where they discuss what they’ve learned that week from working on delivery teams and working with their various stakeholders.  As the result of the meeting several of the enterprise architects may take on action items to update existing EA artifacts.  These artifacts may include EA models, reference architectures, development guidelines, white papers, and so on.  When a new major topic arises, such as the potential adoption of a new platform or a merger with another organization, the EA may choose to schedule agile modelling sessions to explore the topic.

Workflow With Other IT Teams

The following diagram overviews the major workflows that your disciplined agile enterprise architecture activities are associated with.  Note that feedback is implied in the diagram.  For example, where you see the Technology Roadmap and Guidance flow from Enterprise Architecture to Reuse Engineering there is an implied feedback loop from the reuse engineers to the enterprise architects.  Also note that the workflows do not necessarily imply that artifacts exist.  For example, some of the guidance provided by enterprise architects may be discussions with their stakeholders.

Disciplined Agile Enterprise Architecture Workflow

The following table summarizes the workflows depicted in the diagram.

Process Blade Process Blade Overview Workflow with EA
IT Delivery Addresses how to develop solutions in a disciplined agile manner.  This includes the four lifecycles – basis/agile, advanced/lean, continuous delivery, and exploratory – supported but the DAD framework plus the program management blade (effectively a large team following one or more of the lifecycles). Enterprise architecture will provide guidance to the IT delivery teams in the form of coaching and mentoring the teams in architectural issues, providing the technology roadmap, and providing development guidelines (such as coding conventions, security conventions, database guidelines, and so on).
Continuous Improvement Addresses how to support process and organizational structure improvement across teams in a lightweight, collaborative manner; how to support improvement experiments within teams; and how to govern process improvement with your IT department. The continuous improvement activities will provide potential improvement suggestions for improving enterprise architecture efforts.  Similarly, the EA team may have insights to share with the rest of the organization.
Data Management Addresses how to improve data quality, evolve data assets such as master data and test data, and govern data activities within your organization. Enterprise architecture will provide guidance to the data management activities.  Operational intelligence pertaining to production data sources and data activities will be made available to the EA team to support their long-term planning efforts.
IT Governance Addresses strategies for consolidating various governance views, defining metrics, taking measurements, monitoring and reporting on measurements, developing and capturing guidance, defining roles and responsibilities, sharing knowledge within your organization, managing IT risk, and coordinating the various governance efforts (including EA governance). The IT governance efforts will provide guidance to the EA team.
Operations Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations. Enterprise architecture will provide a technology roadmap and guidance to the operations efforts so that their efforts to evolve the IT infrastructure reflect the overall organizational strategy.  Operational intelligence will be used by the EA team to provide insights into the effective of various architectural strategies.
Portfolio Management Addresses how to identify potential business value that could be supported by IT endeavors, explore those potential endeavors to understand them in greater detail, prioritize those potential endeavours, initiate the endeavours, manage vendors, and govern the IT  portfolio. Enterprise architecture provides the technology roadmap to portfolio management.  The roadmap is used as input into identifying potential business value that could be supported by IT and into prioritization decisions.
Product Management Addresses strategies for managing a product, including allocating features to a product, evolving the business vision for a product, managing functional dependencies, and marketing the product line. Enterprise architecture will provide the technology roadmap to product management which is an input into evolving the vision for a product and identifying new potential features for products.  Product management provides the business roadmap and stakeholder priorities to enterprise architecture which is used as input into evolve the enterprise architecture.
Program Management Addresses strategies for managing large product/project teams, allocating requirements between sub teams, managing dependencies between sub teams, coordinating the sub teams, and governing a program. Enterprise architecture will provide guidance to large IT delivery teams (programs) in the form of coaching and mentoring the teams in architectural issues, providing the technology roadmap, and providing development guidelines (such as coding conventions, security conventions, database guidelines, and so on).
Release Management Addresses strategies for planning the IT release schedule, coordinating releases of solutions, managing the release infrastructure, supporting delivery teams, and governing the release management efforts. Enterprise architecture will provide the technology roadmap and guidance to the release management efforts so that their planning efforts reflect the direction of the overall organization.  Operational intelligence will be used by the EA team to provide insights into the impact of current architectural strategies on the overall release effort.
Reuse Engineering Addresses how to identify and obtain reusable assets, publish the assets so that they are available to be reused, support delivery teams in reusing the assets, evolving those assets over time, and governing the reuse efforts. Enterprise architecture will provide the technology roadmap and guidance to the reuse engineering efforts so that they can better identify potentially reusable assets.  Reuse intelligence will be used by the EA team to provide insights into where to focus technical debt pay down efforts.
Support Addresses how to adopt an IT support strategy, to escalate incidents, to effectively address the incidents, and govern the IT support effort. Enterprise architecture will provide the technology roadmap and guidance to the support team so that they can better understand the overall IT ecosystem and the direction it is going in.  Operational intelligence will be used by the EA team to provide insights into the supportability of the various solutions in production.

The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with enterprise architecture and reuse management are fulfilled by a single group.  In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team.  Some organizations may choose to have a separate group for each process blade.  And of course the organizational structure will evolve over time as your various teams learn how to work with one another.  Every organization is different.

Related Postings

 

 

Disciplined Agile Enterprise Architecture: A Goal-Driven Approach

This posting, the latest in a series focused on a disciplined agile approach to enterprise architecture (EA), overviews the activities that a disciplined agile EA team may perform. Some methods will choose to prescribe a single approach, such as capturing architectural requirements in the form of epics or pre-building “architectural runways,” but the Disciplined Agile Delivery (DAD) framework promotes an adaptive, context-sensitive strategy.  DAD does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this blog we present the goal diagram for the Enterprise Architecture process blade and overview its process factors.

The following diagram overviews the potential activities associated with disciplined agile enterprise architecture.

Disciplined Agile Enterprise Architecture

The process factors that you need to consider for enterprise architecture are:

  1. Support stakeholders. Enterprise architects will work with business and IT stakeholders on a regular basis to understand their needs and to help them develop a vision for the organization.
  2. Support delivery teams.  Enterprise architects will work with IT delivery teams, and ideally be active members of IT delivery teams, on a regular basis.  They may guide the teams in the business and technical roadmaps, help them to identify potentially reusable assets, to identify technical debt, and transfer their skills and knowledge to team members.
  3. Negotiate technical dependencies.  Like it or not, there are dependencies between the solutions that we create.  For example, if your system invokes a web service, or calls an API, provided by another system then you have a dependency on that system.  Enterprise architects will often find that they need to negotiate these dependencies with other teams, either at a high-level in their role of Enterprise Architect or sometimes at a detailed level in their role of Architecture Owner on a delivery team.
  4. Tailor architectural framework.  The enterprise architecture team may choose to adopt, and likely tailor, an existing enterprise architecture framework.  These frameworks typically suggest a multi-view collection of artifacts to create and techniques for doing so.
  5. Explore architectural views. Organizations are complex and as a result they must be understood from a variety of view points.  It’s not just a matter of writing “architectural epics” on a collection of index cards.
  6. Evolve enterprise architecture. Enterprise architects will collaborate with one another, and with their stakeholders, in a variety of ways.  They may choose to hold architecture envisioning/modeling sessions or regular meetings where they share learnings with one another.  They will often work together, or with IT delivery teams, to investigate new technologies or identify candidate architecture strategies.
  7. Evolve roadmap(s). An important output of your enterprise architecture effort will be one or more roadmaps describing your technology strategies and/or your architectural strategies. In agile organizations this roadmapping occurs in a rolling wave approach where the roadmap(s) are updated regularly.
  8. Capture enterprise architecture.  There are two broad categories for how enterprise architects can capture their work: as documents or as working/executable examples.  High-level models work well for documentation, although sometimes you may find the need for detailed documentation as well.  Executable artifacts, such as executable reference architectures or architectural runways, are usually preferred over documentation by delivery teams.
  9. Govern architecture. Architectural activities within your organization should be governed in a lightweight, collaborative manner.  This is an important activity for enterprise architects as well as for your IT governance team.

Our next blog posting will describe the workflow of enterprise architecture with other key IT activities such as portfolio management, reuse management, and IT delivery teams.

Related Readings

Agile Enterprise Architecture Team Structures

We learned in a previous blog posting, The Mindset of a Disciplined Agile Enterprise Architect, that disciplined agile enterprise architecture (EA) teams work in a very collaborative manner, evolving their artifacts over time based on their learnings.  But how do you organize an enterprise architecture team so that it can be agile?  Answering this question is the goal of this posting.

As you would expect, the answer is “it depends”.  There is no one right way to organize an enterprise architecture team, your approach must be driven by the context of the situation that you find yourself in.  We start with the strategy that we call the “hands on” approach because members of the EA team are also members of IT delivery teams.  We then describe a small EA team approach, a common strategy when you are first getting your team in place or when the team doesn’t have the funding required for the hands-on approach.  We end with a discussion of how to go about this in very large organizations.

The “Hands On” Team Structure

Every DAD team has someone in the role of architecture owner (AO), sometimes called an agile solution architect or simply agile architect.  This person is responsible for guiding the team through architectural decisions and for mentoring and coaching other team members in architecture and design skills.  An AO should have a solid understanding of your organization’s technical and business roadmaps, if they exist, and be willing to collaborate closely with the enterprise architecture team.  With the “hands on” EA team structure, AOs are members of the enterprise architecture team.  The following diagram shows how an AO is a member of a delivery team and a member of the enterprise architecture team at the same time.

Agile Enterprise Architecture Team Structure

A few important observations about the “hands on” team structure depicted above:

  • The team is led by someone in the role of Chief Enterprise Architect (we’ve referred to this as Chief Architecture Owner in the past).  This person may or may be working as a member of an IT team.  They often spend much of their time collaborating with senior stakeholders across your organization.
  • Sometimes a given person performs the role of AO on several teams, often due to lack of staff with agile architecture skills.  Note that this is generally believed to be poor practice as the person will quickly become a bottleneck.
  • There may be enterprise architects who are not currently working with delivery teams.  This occurs in organizations where the architecture work is sufficiently complex to require people focused on that or because there are more architecture-skilled people available than are currently needed by IT delivery teams.
  • Some delivery teams may not have someone in the role of AO, once again due to a shortage of skilled people.

The AO will spend most of their time (90-95%) working with one or more delivery teams and the remainder working performing enterprise architecture activities.  There are several strategies that you can consider for determining who will be on EA team:

  1. Delivery teams nominate their own architecture owners.  This person must then become part of the EA team.  The primary advantage is that this person will already be a respected member of the delivery team.  The potential downside is that they may not yet have the skills required to be an effective enterprise architect.
  2. The enterprise architecture team nominates someone to be an architecture owner. The advantage of this approach is that the person will have enterprise architecture knowledge and experience.  The potential disadvantages are that the person may not fit well on the delivery team, the team may already feel that it has someone in this role, and that the enterprise architect may not yet have the skills required to be a productive member of the delivery team.  This top-down approach only works well with agile teams when the person being added to the team is both known and respected by them.
  3. Each team nominates someone to work with the other team. With a holocracy-based approach, when there is a need for two teams to collaborate with one another over a period of time each team nominates someone to work with that other team.  This helps to ensure that the priorities of both teams are addressed and ensures more effective communication between the teams, although has the drawback of requiring more people split across teams.

The “hands on” team structure is typically used by:

  • Architecture-oriented organizations.  This strategy is common in organizations willing to make a significant investment in enterprise architecture.
  • Large programs.  In this case it ends up being an architecture owner team for the program, or a program architecture team, and not a true enterprise architecture team.

The Small Enterprise Architecture Team Structure

The following diagram depicts what we call the “small EA team structure.”  In this case external teams will submit a request for the EA team to do some work.  These are typically requests to review their work or to provide some guidance on an architectural issue.  The enterprise architect(s) will address the requests in priority order, often working in a Kanban-style manner.

Small Enterprise Architecture Team Structure

This small EA team approach is common when EA teams are starting out or when they aren’t adequately funded to have people on every IT delivery team.  Although it is possible to keep this lightweight, and that is often a necessity due to funding constraints, it can sometimes devolve in to a review-based, documentation heavy approach.  Furthermore, due to understaffing the enterprise architects rarely have the time to coach others in architectural skills.  In extreme situations the EA team becomes a bottleneck for the IT delivery teams waiting for help from them.

The Multi-Level Enterprise Architecture Team Structure

Very large organizations, often those with thousands and sometimes tens of thousands of people in IT, need a more sophisticated approach to organizing their EA team.  In these situations they tend to have a multi-level approach.  For example, we have one customer who is taking a three-level approach to the hands-on team strategy described earlier.  The first level is enterprise architecture for the line of business within a specific geographic region (i.e. retail banking in Europe), the second level for the geographic region, and the third level for the overall company.  With this strategy someone is an AO on a delivery team and a member of the first level EA team.  The chief EA of the first level team is a member of the second level team for their geographic region, and the chief EA of that team is a member of the organization-level EA team.  In short, this multi-level EA team structure reflects the overall organization’s structure.

Context Counts

Each EA team structure described in this blog has advantages and disadvantages. No one approach fits all situations, and as the context of the situation that you face evolves over time so will the structure of your enterprise architecture team.

Related Readings