This website uses cookies to store information on your computer. Some of these cookies are used for visitor analysis, others are essential to making our site function properly and improve the user experience. By using this site, you consent to the placement of these cookies. Click Accept to consent and dismiss this message or Deny to leave this website. Read our Privacy Statement for more.
Contact Us   |   Sign In   |   Join Us
Requirements Team Blog
Blog Home All Blogs
If you’re a practitioner of business architecture, the words visibility and transparency should be music to your ears. Nothing cries out for the skills and talent of a business architect more than the need to develop a business blueprint that defines the current-state business model and provides a roadmap to the future expressed in business strategy, business impacts and the need for business-driven IT transformation.

 

Search all posts for:   

 

Top tags: Agile  SAFe  Agile Release Train  architecture  Backlog  Business Requirements Team  Capability Gaps  Metamodel OMG BMM  Prioritization  Value Streams 

Who's On First? Architecture Roles and Responsibilities in SAFe

Posted By Cari Brose, Thursday, March 9, 2017
Updated: Thursday, March 9, 2017

Scaled Agile Framework (SAFe) is a framework for delivering solutions that deliver business value, scales Agile, and incorporates lean principles and practices into the enterprise. While business architecture is not directly referenced in the latest version SAFe (v4.0), enterprise architecture, solution architecture, and application architecture are referenced. (To get more information about SAFe, see the SAFe Big Picture at http://www.scaledagileframework.com/ and click on the icons to get details about terms). Business architecture also needs to be integrated into the Portfolio-level activities to ensure strategic alignment, prioritization, architecture, and deliver the right solutions.

 

The reason that the Portfolio is the most logical place to start is that business architecture gives us a solid foundation for defining the right work based on strategy. By employing stages within the Business Architecture value stream (see figure 1) as part of Portfolio management, we can analyze our business to discover and articulate where we should be focusing our solution efforts. The business architecture value stream’s Assess and Refine Business Strategy value stream stage overlaps with the Strategic Themes development process in SAFe. The Establish Initiative Plans value stream stage and the SAFe Portfolio Kanban process also overlap, since the Kanban exists to capture, analyze, approve, and track epics. In SAFe, the epics are put into the Portfolio funnel of the Kanban for processing. The goal of both is to define and prioritize the enabler and business epics. Currently in the SAFe Portfolio, however, there are no interim activities or deliverables indicated between the Strategy and the Kanban. Strategic Themes are used as decision-making filters for Epics in the Kanban. The core business architecture domains of value streams, capabilities, information, and organization gives us a rich palette for better understanding where to focus our efforts to deliver the strategy. The integration of business architecture would also facilitate the Review and Analysis activities that take place in the Kanban.

 

 Figure 1: The Business Architecture value stream[i]

 

By starting with the business strategy (equivalent to starting with strategic themes in SAFe), the business knows where to focus its efforts in order to achieve its goals. Since business architecture is intended to implement strategy, business architecture engagement starts with the Establish / Refine Business Strategy value stream stage. This requires a partnership with the Program Portfolio Management (PPM) team, including the enterprise (technical) architect to ensure the strategy is analyzed, understood, and articulated as objectives that are bound by the various business architecture mappings, particularly value streams and capabilities. This architecture binding helps focus on the intention of the objectives and value received, and further, on what changes are needed to move the business forward as well as architect transformational solutions. If an epic is presented that is not tied to an objective associated with one or more value streams, the Business Architect should facilitate discussions with the PPM team and business leaders to drive out strategy and update the epic accordingly, or recommend rejecting the epic. There are many tools available to help with this, such as the business model canvas.

 

Business Architects can start to engage prior to the Portfolio Kanban process by translating the strategic themes into epics. Business architecture then becomes the crank that turns the implementation machinery of SAFe to provide more value to the business. It does this by identifying and resolving the gaps and inefficiencies discovered through the analysis of the business capabilities, value streams, information needs, and organizational structure. Figure 2 shows how the initial stages of the business architecture value stream could integrate with SAFe.

 

Figure 2: Integrating the business architecture value stream with SAFe

 

The business architect’s role is distinct and separate from the other SAFe architecture roles, but complements those roles by providing a baseline understanding of the business and context for the solution. The enterprise architect’s role in SAFe is to provide architectural governance, technical direction, collaboration, and holistic solution deployment strategy across SAFe value streams at the Portfolio level, creating enabler epics to foster technical change. The solution architect then starts to lay the architectural runway for the SAFe value stream by creating the architecture design with a systems view, based on the direction given by the enterprise architect. Part of this entails creating a future or end state for the architecture, then developing a transition plan to move the company from its current state to that end state. In order to do this, the enterprise architect and the solution architect need to understand the business needs as well as adaptive design practices. The business architect is the one who provides that understanding of the business through various mappings and analysis. Without that business context and understanding, the architects are designing components based on limited knowledge, which can lead to incomplete solutions that fail to meet the business needs.

 

The analysis done by the business architects also facilitates the epic owner’s work. When an epic is approved to go from the Funnel to Review, then on to Analysis in the Portfolio Kanban, the Epic Owner has responsibility for creating the Lightweight Business Case. This requires taking a deeper dive to analyze the size, impact, and the benefits of the epic. By using the information that the business architect provides, the epic owner has a far better understanding of the scope of the epic as well as the benefits it will deliver by closing gaps. This should reduce the amount of analysis needed to shepherd the epic to the next phase. The epic owner can use the business architect as a resource to identify the actions needed for the epic to realize the objectives. This consulting role for the business architect continues into the Value Stream and Program levels within SAFe, working with the solution manager and the product manager roles, respectively.

 

SAFe is still maturing and business architecture should be part of that maturity process. Business architecture can be an integral part of making the agile framework, i.e. SAFe, work smoothly and effectively. By engaging business architects to perform analysis at the Portfolio level, the business can identify the right approach to solve a business problem. Business architects should work hand in hand with other SAFe Portfolio level roles to provide business context and develop epics that can then be prioritized and developed to realize strategy. In this way, business value will be more readily achieved and everyone benefits. By integrating a value stream for business architecture analysis into the Portfolio to feed the Kanban, we can have an intentional method for communicating and aligning with SAFe and consistently implementing the role of the business architect.   

 



[i] Business Architecture Guild, A Guide to the Business Architecture Body of Knowledge®, v 5.5 (BIZBOK® Guide), 2017. Part 1 and Appendix B.1

Download File (DOCX)

Tags:  Business Requirements Team  SAFe 

Share |
PermalinkComments (0)
 

Keeping the "trains" on the track

Posted By Jeffrey Wallk, Friday, December 9, 2016
As folks begin embracing various methodologies to address the accelerating pace of business, they will continue to struggle with basic communications, integration, and interoperability (within an organization & across value chains). This is going to create stress points and increase the operational costs due to refactoring and ongoing problem resolution. There's increasing focus around agile methodologies to deliver value faster, none more interesting and well thought out than the SAFe framework. The framework provides requirements teams and business analysts with a way to decompose the value streams and deliver focused value using trains.  The concepts are useful and can reduce cycle time.  As teams embrace these types of methodologies, they should consider engaging architects to define and "build" the tracks so the trains run on time and don't run aground (or worse into one another). Some of the emerging artifacts that will help with the design of the tracks and address the growing concerns with communications are the metamodels and architectures that provide a reference model for guiding the designs and alignment of communications (between humans, within systems & across systems). These metamodels are still evolving as are the architecture disciplines themselves, so requirements teams and business analysts will want to engage the services of business architects to help navigate areas of uncertainty while these standards and disciplines continue to evolve and mature. Perhaps we can think about business architecture as a way to stay SAFE while we leverage SAFe. 

Tags:  Agile  architecture  Metamodel OMG BMM 

Share |
PermalinkComments (0)
 

Business Architecture and SAFe: The Courtship Begins

Posted By Renee Batts, Tuesday, September 13, 2016

Every year I notice the executive leaders in my organization have a new set of words they embrace and begin to use as part of their everyday language.

 

Over the past few years, those words have started to include: Visibility. Transparency. Agility.

 

Big words.

Tall orders.

Culture changers.

 

If you’re a practitioner of business architecture, the words visibility and transparency should be music to your ears. Nothing cries out for the skills and talent of a business architect more than the need to develop a business blueprint that defines the current-state business model and provides a roadmap to the future expressed in business strategy, business impacts and the need for business-driven IT transformation.

 

Business architecture is becoming a vital ingredient in the quest to achieve transparency. At its core, business architecture provides blueprints that include:

  • Business capabilities that define what a business does
  • Value streams that define the value a business provides to its stakeholders, especially customers
  • Information concepts that reflect the type of information the business cares about; and
  • Organization mapping that illustrates the structure of the organization and its partners

 

These business blueprints, especially the capability map, are the launching point for identifying capability gaps within the organization, prioritizing future needs, assessing the impact of change, and evolving the business model based on business strategy. These perspectives facilitate a common vocabulary among business and IT stakeholders, that cuts through layers of assumptions and misunderstandings.

 

The current and target state architectural views of the blueprints also eliminate a common organizational hurdle: strategy diffusion. Studies suggest that the strategies defined by executive leadership are carried down from one management level to the next and by the time the teams who are performing the work to implement those strategies learn about them, 17% of the original intent is lost in each translation. Through just three levels of communication and confusion – CEO to senior leader to management to a team – nearly half of the original intent can end up being miscommunicated or misconstrued!

 

Understanding the future state of the business is critical to executing any strategy or business transformation. But what difference does that understanding make if it takes us five-to-ten years to execute on the strategy? Will our strategy be the same five years from now? Will the business blueprint even look the same? With the speed of change in business today, the answer is almost certainly, “No!”

 

Business is on a fast track of innovation, digitization, and hyper-competition. Every day there are stories coming from companies around us – often those we wouldn’t have anticipated – who have identified a disruptive idea that changes the way we do business. It changes the way our customers relate to us as a company, and more importantly, it changes what our customers expect as the norm from everyone they do business with, whether that expectation comes from within our industry or not. The ease-of-use of today’s mobile devices, for example, transfers that expectation to all kinds of consumer experiences, from insurance to online shopping to news consumption to social media.

 

How do we keep up with the need for innovation and the speed that our business partners both want and need to make changes? We have to introduce agility into our business and technology solution development processes.

 

Over the past several years, organizations have been transitioning their approach to software and solution development. Waterfall methodology reigned for decades, but it was a source of constant frustration between business and IT partners. By the time a large strategic initiative was implemented – it was often years after the original requirements were gathered. What the business got was no longer what the business needed – and that’s assuming the IT partners understood what the business wanted in the first place.

 

Enter “agile”. The agile methodology breaks large, monolithic efforts down into smaller pieces and enables teams to gather requirements, develop, test and release in shorter increments – providing business value sooner and eliminating the multi-year wait. 

 

However, one of the downsides of a single-threaded agile approach – where individual teams take a “project” at a time – is the overhead. A new agile project team is created to work on one specific strategic initiative, and then disbanded at the end of the project closing cycle. Think about it: after our agile team has gone through forming, storming, norming and performing, we break them up and ask them to start all over again. Ouch. Inefficient.

 

That’s where Dean Leffingwell and his crew of methodologists saved the day. He developed the Scaled Agile Framework – SAFe. The premise of SAFe is to eliminate the constant churn of project start-up and closure. Agile Release Trains are established to work on specific types of work; agile teams that are part of each train stay in place. The work a team receives may change over time, but the team remains intact, able to pivot to whatever the business has deemed highest priority.

 

But, wait. How do you decide what type of work goes to each train and how do the agile teams know when to pivot? This is where the courtship between business architecture and SAFe begins. 

 

When it comes to business architecture and SAFe, well, SAFe had me at value stream.

 

The SAFe structure works best when it is organized by value stream. Agile Release Trains are clustered around a value stage or a series of value stream stages within a value stream. In other words – the release train works on a common aspect of the business.

 

Think about a mortgage purchase, the customer’s value stream is probably something like this:

  • Find New House
  • Determine Need
  • Apply for Loan
  • Complete Loan
  • Close on House

 

In the SAFe structure, one train may be completely focused on the Apply for Loan value stream stage and nothing more. Or, if the business need is broader, it may include three or four or even all five value stream stages. The point is that the train will focus on providing business value around the same value stream or value stream stages without the disruption of opening, closing, or shifting teams.

 

All of the teams in the same train work from a single program backlog that is prioritized by business value. And the best part yet – the backlog is managed by a member of the business. That business stakeholder, working in collaboration with the business architect, is able to use business architecture assessments and blueprints to identify and prioritize the list of gaps and strategies. This provides a transparent framework for the business to determine the priority order of items in the backlog, and a consistent vocabulary and structure for IT partners to understand the work they are being asked to do. The items with the highest business value rise to the top. And, with a progressive business partner, the small defects that provide little to no value are eliminated.

 

The IT developers who work on the agile teams within SAFe don’t code any faster than they did in the waterfall methodology, but the focused effort on the right items to deliver business value make it look that way.


The executive leaders in my company are still talking about visibility, transparency and agility. But not in the context of needing to learn to be more of those things, but with a sense of excitement over what we’ve accomplished, and of course – an eye toward how to make this better as we move forward.

 

Over the coming months we’ll be sharing additional blogs on the relationship between Business Architecture and SAFe. We welcome your feedback, comments, and participation in the process.


 

Tags:  Agile  Agile Release Train  Backlog  Capability Gaps  Prioritization  SAFe  Value Streams 

Share |
PermalinkComments (2)
 


Association Management Software Powered by YourMembership  ::  Legal