Written by Mark Tappan
on November 07, 2018

Using Integrated Problem Solving to Bridge Enterprise Architecture and Agile Projects

We often see a discontinuity between enterprise and project teams driven by full-time focus and dedication to their objectives with little time for interaction with one another. Each project team optimizes their releases to meet their stakeholder goals resulting in sub-optimal (or in some cases dysfunctional) enterprise solutions. Meanwhile, the enterprise teams develop architecture patterns, interfaces and standards that have the potential to optimize the enterprise solutions, but their results often languish as shelf-ware. New requirements and opportunities are brought directly to project teams in haste to turn out new releases. Enterprise teams struggle to maintain relevancy and accuracy of their work products which are used by leaders to make decisions on future investments. Not an unfamiliar story I’m afraid.

Fortunately, we have a couple of tools that help counterbalance these effects.

  • Architecture and process frameworks help capture, document, and share enterprise and project perspectives available
  • Integrated Problem-Solving approaches that pull together enterprise teams and their project teams and their customers and immerse them in solution development efforts
  • Ultimately, both groups have the passion that to give users what they really want/need to do their jobs

There are several great well-thought-out and industry-proven frameworks that encompass the engineering and “soft-skill” practices, tools, and standards necessary to create system-of-systems or enterprise portfolios. Here are a couple of examples.

  • There are a several great reasons why development teams adopt and practice the principles espoused by the Agile Manifesto. In my experience, emphasizing customer satisfaction through active participation and embracing a build-measure-learn philosophy are two critically important benefits. Both help reduce uncertainty of what customers really want and will use and bridge the gap between user and technical languages.
  • Scaled agile approaches, such as the Scaled Agile Framework (SAFe), show us that there is often a larger context that must be considered, and it is of equal importance to building the right solutions. This larger context describes how the individual solution must fit and work within the enterprise environment which may extend to multiple organizations. The context is at the heart of enterprise investment and management constructs such as IT Portfolio Management or SAFe Portfolios.
  • Architecture frameworks, such as the Department of Defense Architecture Framework (DODAF), help organizations define, document, rationalize, and share the larger business, organizational and technical context that ultimately empowers and constrains individual solutions. Enterprise architecture teams tackle issues that are similar to those of individual solution teams – what mission, operational and/or IT capabilities do stakeholders want from a strategic capability, and how do we capture and convey those needs.

You can apply frameworks to connect your strategic imperatives, operational capabilities and system services together to form a Digital Thread.  The digital thread created by connecting enterprise and project level information links multiple perspectives on the systems and solution you develop and enables accurate and informed decisions on prioritization, investment, and performance across multiple levels of the organization. Senior leaders can invest or divest based on business objectives and operational data; product owners and managers can make priority decisions based on business and end-user needs; and technical leads can make decisions that drive change back into larger the ecosystems.

Frameworks and business drivers alone are not enough to create and sustain (often harder than creating them) digital threads. We need to incorporate a sense of common destiny that emphasizes the symbiotic relationship between enterprise and projects.

We believe an Integrated Problem-Solving (IPS) approach is the key for balancing the focused demands of solution-seeking stakeholders with the broader goals of enterprise optimization stakeholders. An IPS approach immerses multiple stakeholders with traditional and non-traditional problem-solving techniques and experts. I’m a firm believer that people usually understand better what other groups are trying if they are embedded in the action. And by embedded, I mean an active part of the action not just a spectator. Too many times, I’ve seen end-users brought into development teams just to watch the action.

Day in the Life Technique

Using an IPS approach like Immersive Engineering, multiple stakeholders bring together different and occasionally conflicting perspectives on solution priorities and objectives and use multiple techniques to decide on a plan (or plans) of action to solve technical and non-technical business needs. Stakeholders use different views from the organization’s enterprise framework and IPS techniques to modify and enhance the enterprise to deliver new capabilities.

We can employ techniques such as Day-in-the-Life to describe how strategic capabilities require interoperability across multiple project teams and engage project teams in developing the feature stories to enable that interoperability.  This technique creates multiple perspectives:

  • You use this technique to place the user in the center to explain and draw out a new enterprise capability without regard for applications or system connections
  • You place the enterprise architect in the center to explain the connections between enterprise services
  • You place the project team in the center to help identify epic and features stories that focus on integration and interoperability. You can capture comments and questions in real time on stickie notes as shown in the figure
Operation Event Trace Models

Once you are working between enterprise and project teams, or between multiple project teams, or perhaps working non-development activities such as process or regulatory compliance development, you can use additional techniques to hypothesize, test, and refine solutions that adhere to enterprise interoperability and compliance standards while enabling innovation at the project level. For example, building on the Day-in-the-Life technique, you can develop operational event traces to show how individual user interactions trace through features from different project backlogs (represented as different colored stickies).

These two figures illustrate how Immersive Engineering techniques help create digital threads for an organization by pulling together enterprise and project teams with their respective customers to work on both perspectives. These frameworks provide a basis for collecting and managing the digital thread information, but it’s the soft-skills that bring the engineering and mission skills together.

Interested in learning more about integrated problem solving? Attend our Integrated Problem-Solving Forum on December 4!

Register Now

Let Us Know What You Thought about this Post.

Put your Comment Below.

You may also like: