Enterprise Architecture, BPM and Agile: The Old, The New, and What To Do

This guest article by Mike Idengren about scaled agile architecture is complimentary to the interview that we did with Mike in Episode 6 of the What’s Your Baseline podcast.

THE  BIG GOAL: The timely release, operation, and maintenance of quality assured products and services in a cost effective way.  

While “The Big Goal” is transformative and generally requires changes to culture, technology and ways of working, this LeanPaper will focus on one of the most difficult balance to strike when scaling agility beyond small teams:  

• How Agile Architecture (and Architectural Runway) fit into the picture.  
• We will discuss what’s old, what’s new, and take a broader people/culture-inclusive look at practical ways that teams, programs, and organizations can improve progress towards The Big Goal, no matter what their maturity is.  
• Finally, we will discuss “4 gears” to scale and align Architectural Runway with business and DevOps. 

What’s “Old”?

It’s better if Business and IT can work together to develop products.  Business folks typically won’t know the details of “what it really takes” to release, operate and maintain quality assured IT services in a cost effective way.  IT folks typically won’t know the business product details (e.g., customer journey & business processes) and can’t move at the speed business expects (e.g., changing – or misunderstood – requirements).  Enterprise/IT Architecture and Business Process Management are not new, and have attempted to bring business and IT together using various tools and techniques – but expected value frequently eludes. 

What’s “New”?

Expectations of faster time-to-market for quality-assured products and services, even as customer expectations (and requirements) change rapidly.  Agile solutions (beyond just agile “software”) are needed to meet these expectations, and most organizations are at some point in their journey implementing agile frameworks — such as Scaled Agile Framework for Enterprise (SAFe) — using small teams and projects, with varying degrees of success.  Large investments still need to be made (e.g., technology infrastructure, ERP systems, development tools) but such large investments can limit flexibility (and thus speed) of teams “on the ground” who want to deliver customer value without all the “red tape”.  So how do we balance this, keeping The Big Goal in mind? 

The answer is Agile Architecture, and by extension, Architectural Runway (according to SAFe:  “the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay”).  Some tangible benefits of striking the correct balance are: 

• Improved product speed-to-market:  Less “re-inventing the wheel” by improving EA artifact re-use and “chunking” bits of work to improve collaboration among developers and product owners (where “chunks” can be epics, features, and/or user stories).  For example, linking product/service features to relevant EA artifacts such as a business-validated process, or an IT-approved application / microservice. 
• Improved product quality & lower risk:  Improve testing by accommodating test cases that reflect “real life” business processes and related Governance, Risk and Compliance impacts, including use of Behavior Driven Development and Test Driven Development.  For example, linking user stories to detailed process steps, risks, controls, and/or applications. 
• Improved sustainability:   Make the case for the right investments in tools and technologies (e.g., EA/BPM software and Cloud services) to accelerate speed/flexibility & quality.  For example, performing regular application portfolio rationalization.  

Making it happen

Ideally, an organization will commit to a new (agile) way of working, and follow through with time, resources and ongoing leadership.  Sometimes, leadership will make broad “Big Bang” commit to such transformational change in response to external forces (e.g., disruptive market forces and/or new technology).  However, frequently, organizations may ask existing teams, programs, or Line-of-Business leaders to “start small” and “see how it works here”.  In either case, a two-step approach is recommended: 

1. Start small (6-8 months):  Launch a pilot – for example, getting Leadership permission and “air cover” to deliver a simple product that has little-or-no enterprise risk/compliance/IT dependencies.  It can be helpful to bring in an agile-experienced integration partner. 

• People / Culture:  Build cross-functional teams to break up the “department” mindset.  Deliver SAFe training and specialize persons in key roles (e.g., Business Analyst, Product Owner, Developer, System Architect), giving them “time and space to shine”.   
• Architecture Runway / Tools:  Basic, cloud-enabled/lightweight Kanban-Scrum tools (e.g., JIRA), software development and BPM/EA tools. 
• Architecture Runway / Processes & Governance:  Lightweight, informal, and minimum needed for compliance.  In this small pilot, lessons can be learned as the IT Architect works with developers and others in the IT department.  However, dependence on heavy risk/compliance and/or IT committee approvals may “choke” the pilot at this point of maturity. 

2. Scale it up (Y1, Y2, Y3…):  Pick a cross-department product/service, preferably inclusive of multiple business areas; set bigger goals, add more people, lay more runway. 

• People/Culture:  Leadership commitment and training (broad and specialized).  Include operations and maintenance roles, adding key partners and suppliers (and including them in up-front training and messaging). 
• Architecture Runway / Tools:  Invest in a Continuous Delivery Pipeline (CDP), including portfolio-integrated agility-at-scale tools (e.g., JIRA Align) and BPM/EA tools that have powerful integration capabilities (e.g., Software AG ARIS/Alfabet). 
• Architecture Runway / Governance:  Rethink collaboration and internal processes between agile cross-functional teams and existing governance bodies (e.g., BPM / EA / IT) and a new Lean-Agile Center of Excellence (LACE). 

Scaling Architecture Runway capabilities

As the larger organization moves to scale agile benefits to larger products/service portfolios, it is important to match the scale of Architectural Runway.  Architectural Runway scaling details are discussed in BIZ.ARCH+DEVOPS – Value Beyond Coding, broken into four maturity stages: 

• 1^st Gear:  Tailor & Adopt BIZ.ARCH+DEVOPS.  Business Architecture (BIZ.ARCH) expands a DevOps Continuous Delivery Pipeline, bringing business & IT into the same “Product Development Lifecycle” 

• 2^nd Gear:  Pave Three Architectural Runways.  Create “just enough” structure and standards needed to improve testing quality, control technical debt, and speed up future design efforts. 
• 3^rd Gear:  Continuous Exploration / Continuous Integration (CE/CI) with Model-to-Execute (M2E).  Runways are paved during CE, and “used up” during CI, leveraging BIZ.ARCH for scalability and agility. 
• 4^th Gear:  Maintain Runways for a Healthy Product Portfolio.  Ongoing BIZ.ARCH+DEVOPS maintenance is needed to ensure quality runway for future product enhancements and variants.