What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

Developing an EA strategy is not done very often, but has many benefits. In this episode we are talking with Carlisle Gunn, an experienced Enterprise Architect, who we've worked with on past projects.

Carlisle has worked in the Enterprise Architecture space for over 8 years with a focus on business and application architecture. He led teams through process discovery into documentation and improvement. Working with team members from a wide array of roles, his background demonstrates experience working with almost every type of functional member within an organization.

Carlisle received a Masters of Professional Studies in Enterprise Architecture in 2016, where his focus was on the establishment of Enterprise Architecture capabilities and usage of modeling languages.

We are talking about the following topics:

• Carlisle’s background (and some rugby geekery)
• EA strategies and that they need to be client-specific
• Stakeholders and the Enterprise Architect view (top-down) vs. the Solution Architect perspective (bottom-up)
• ARB /= implemented EA strategy
• Components of an EA strategy
  Start with maturity assessment > identify low-hanging fruit
  Communication is part of the “how”; EA strategy is the “what”
  EA goals and how to measure EA KPIs
  EA capabilities and services

Welcome to the first episode of our season 2! Today we are talking about the Solution Lifecycle in architecture - what it is and why it is important to you.

Architecture development and analysis does not happen in a vacuum, but are embedded in a lifecycle. New tools like Process Mining and Task Mining make it sound as if you don’t need other tools and techniques anymore, but quite the opposite is the case - traditional analysis techniques are still needed to support all phases of the solution lifecycle. We are talking about:

• What is a "solution" and what are the layers and phases of the lifecycle (see also graphic below)?
• Give examples of two analysis types and when to use which one best: Simulation and Process Mining
• The value of this iterative approach and the cautions
• The iterative nature of it and the impact on developing your overall architecture approach

Here it is - the end (of season 1 ... no worries, we're back in January 2022). In this episode we are mixing up the format a bit and are talking about the 10 things that we learned in 25 years of  architecture and process management.

Approach / strategy segment

Let's talk about the bigger picture, the why and larger setup. What are the thoughts that get organizations started?

• Why: You’ll end up paying for it somehow. End of the line in people or risk.
• Don't do a "big effort upfront"
• Develop and create in releases / have a release plan
• Processes and architectures need to be measured

Organizational segment

Architectures win and fail with the people. If they don't want to cooperate or be involved you will fail.

• It's the people, stupid
• Do not separate areas of your architecture into different groups
• Risk & Controls folks are your friends

"How-to" segment

Once you get started the task of developing an architecture seems daunting. This segment has a few tips to make it more manageable.

• Start small but don't settle on the lowest denominator - choose a tool and have a minimum set of artifact requirements
• Have the full lifecycle in mind and don't get distracted by the latest tech
• When developing models do this in multiple iterations (esp. processes)
  

Ahh, "governance" - the topic that is boring to death and had complete EA groups being fired.

Love it or not, setting up the "rules of engagement" is still an important piece in an organization. And you can do it while having some fun when you remember the points that we are talking about in this episode:

• Role of governance in architecture activities and how it was seen in the past
• Archetypes of architects - governance as low/low activity (and hence the popularity of EA groups to focus on this topic)
• Who should be involved when setting up the rules of engagement
• Governance automation and how to implement it
• How to design governance processes - push/pull communication, elements of the implementation, measure gov. KPIs
• Organizational design for governance - three branches of governance (legislation / standards group; jurisdiction / ARB; executives / CoE), centralized / decentralized governance setups
• Additional aspects: enablement, project tracking, workload balancing, content freshness, confirmation management, dashboards / hold participants accountable / workflow routing / visibility
• Two client project examples