Enterprise Architecture Work Management
What is Enterprise Architecture Work Management?
How to Transition the Architecture Development Method into Work Product
Planning for Architecture Deliverables
- Align to the Business Cycle
- Predictable Architecture Deliverables
- Unplanned Architecture Deliverables
What is Enterprise Architecture Work Management?
Work Management is a systematic approach to orchestrating a process-enterprise processes, or routine tasks. Good work management is collaborative. Coordinating people and work across all levels of an organization.
Enterprise architecture process are not simple business peocesses. They are a complex set of activities that develop knowledge and architecture decisions. The premier Architecture Development Method, the TOGAF ADM, is a logical approach to developing knowledge.
Enterprise architecture work management orchestrates the development of knowledge. Architects will:
- gather information
- re-use information from their EA repository
- perform analysis
- obtain stakeholder decisions
- guide implementers
Basics of Productivity from Work Management
The high productivity enterprise architects we work with are 10 to 50 times more productive. That's right, 10 to 50 times. There is a huge difference between the best and the average.
These productivity numbers come from the basics of productivity - waste & speed.
Waste
A high fraction of architecture work is waste. It is work done after decision or work done that never leads to action. The best EA teams waste more than 25% of their time. Many average teams we work with never use 80-90% of their work product. 80-90% wasted effort.
Speed
The reverse of waste is speed. With speed, you create useful architecture faster. You gain speed from four things:
- reference materials
- standard analysis supported by formal modelling
- stakeholder engagement
- day-to-day work management
How to Transition the Architecture Development Method into Work Product
The architecture method ends with deliverables. Stakeholders and implementers consume deliverables, not architecture.
Enterprise architecture work management starts with breaking architecture deliverables into work products. Then using the work products to earn architecture decisions. This path ensures the architects have the necessary knowledge and analysis completed prior to engaging stakeholders with architecture alternatives.
The Practitioner's Guide uses an outline of the knowledge creation activities in each of the four standard enterprise architecture use cases. For example, Architecture to support Strategy has four top-level knowledge creation activities:
- Understand Context
- Perform Assessment and Analysis
- Define Approach to Target State
- Finalize Architecture Vision/Target State
Each activity is focused on different knowledge the architect needs. Each identifies the different TOGAF ADM Phases that must be used to create different knowledge.
Translate from the architecture development method to actionable work through a Work Breakdown Structure (WBS). A WBS is deliverable-oriented breakdown of a project into smaller components.
In Navigate we look for these different types of work products:
- information gathering work product
- analysis work product
- deliverable
- architecture decision record
Enterprise Architecture WBS Practices
When crafting the WBS we identify the knowledge required for a deliverable or architecture decision. Yes, a decision is action not a thing, so to make the WBS concept fit we use an architecture decision record. you have specific work products, such as a Stakeholder Map, or a Capability Map.
The WBS lists the you the work products required the create the knowledge artifacts we need. Breaking down the Navigate categories we get a deeper WBS
- information gathering work product
- analysis work product
- view
- assessment work product
- architecture alternative work product
- architecture models
- architecture decision record
- target architecture
- transition stage
- gaps
- work packages
- architecture specifications
- architecture roadmap
- deliverable
- architecture contract
Returning to the example of Strategy and the first set of knowledge creation activities: Understand Context. We have a set of information gathering work products:
Strategy Understanding Context's Information Gathering Work Products include:
- Company Financials
- Inflight Initiatives
- Strategic Goals
- Risk Appetite
- ….
From a work management perspective you either have them in your EA repository or you need to go get them. The latter is work that must be managed.
Work Management Practices
Enterprise Architecture Work Management iteratively builds:
- Information Gathering
- Analysis
- Architecture Decision
The WBS starts with the knowledge we need. Building to analysis work products minimizes waste. The most common waste is uninformed analysis. Starting analysis, or trying to obtain an architecture decision before you have the necessary knowledge is 100% wasted effort. Architects wasting effort usually use the argument the analysis or decision is important!
Use the WBS to capture everything important and make sure that your EA team is not wasting time.
Avoid working past an architecture decision. Engaged stakeholders can provide feedback. Moving forward without requires very good judgement and ensuring you are aligned with the decisions a stakeholder will make. Otherwise, work past an artificial decision is waste.
Planning for Architecture Deliverables
Every organization has a normal business cycle. Parts are formal, like the budgeting process. Some is informal, like delaying the start of serious initiatives to Q2, by using Q1-to get ready
Enterprise Architecture work management embraces these cycles.
Align to the Business Cycle
The diagrams below show two different view of aligning to the business cycle.
On the left is a calendar view:
- financial reporting both spend in revenue
- formal budgeting, preparation submission and approval
- project cycles from approval to kick-off to execution to benefit realization
- risk and compliance assessment and reporting
- sprint based software development
On the right is an initiative planning view. It aligns enterprise architecture use case with an initiative's approval cycle.
Predictable Architecture Deliverables
At least half of all architecture projects and deliverables are predictable. For example, an annual budget cycle requires the senior leaders to think about budgeting categories in Q2. Budget owners will use Q3 for their budget submission. The budget will be finalized in Q4.
Aligning to this cycle requires the EA Team to deliver different budget support in Q1, Q2, and Q3.
Predictable deliverables form the backbone of enterprise work management.
Architecture to Support Portfolio
The enterprise architecture use case Architecture to Support Portfolio is the most predictable.
Change initiative portfolios will be tightly aligned to the budget cycle. Architecture supporting development of the portfolio roadmap operates on one cycle, and architecture supporting implementation follows the portfolio roadmap.
Digital product portfolios will be aligned with the product lifecycle. Consumer-oriented digital products will be typically aligned with a consumer sales cycle around American Thanksgiving and Christmas.
Unplanned Architecture Deliverables
Unplanned architecture deliverables fill in around the predictable work plan.
The use cases supporting Strategy and Solution Delivery are the least predictable use cases.
Strategy development never stops happening. It will be loosely aligned to a budget cycle.
Some Solution Delivery and Project oriented work can be extrapolated from a portfolio roadmap.
Frankly, little architecture is a complete surprise.
Day-to-day Enterprise Architecture Work Management
Day-to-day Architecture Work Management is about improving productivity. Productivity is the amount of completed useful work product per hour of effort. Don’t confuse productivity with overwork. Overwork is a symptom of low productivity.
We are surrounded by the basics of personal productivity at least a thousand times. Our language is filled with productivity idiom. “Working on the first things first.” “Failing to plan is planning to fail.”
Kanban
Kanban is based on three concepts - promised delivery, work, and available workstations.
The WBS we highlighted provides you with the foundation of a work plan, you know what needs to be done.
Predictable architecture deliverables are the easy promised delivery dates.
Your EA team provides you with work stations - which stations can gather information? which can perform business architecture analysis? And so on.
We use Kanban to manage architecture delivery.
We plan our work using six questions:
- Is it in our repository?
- Who on the EA Team is best to do it?
- Who on the EA Team cannot do it?
- Who on the EA Team has time to do it?
- Where should it be in the repository?
- What day is the last day I can live without it?
Then you simple manage a dynamic Kanban board.
Conclusion
Enterprise Architecture Work Management is the difference between a good and a great Enterprise Architecture Team. Great EA teams are 10 to 50 times more productive. They have the guidance ready when the stakeholders are ready to select between alternatives and make architecture decisions.
Great architecture teams waste less time. They miss fewer moments to engage with stakeholders.
Using a WBS encourages re-use. Re-used information gathering and re-used analysis. Using architecture models, further encourages re-use. The information and analysis are recorded in consistent terms. The last tool to improve re-use are standard deliverables. These tools form a core of your architecture framework.
Enterprise Architecture Work Management helps enterprise architects translate their architecture development method to a day-to-day architecture process.
To pick-up these skills look at the Enterprise Architect's Kickstart.
To develop your EA Team's productivity talk to us about developing your EA Team.