The Enterprise Architecture Canvas: Shifting from Archaeology and Architects, Putting Agility into the A of Architecture
Rich Harris
Tech Strategy | Digital Acceleration | Value Based Delivery & Flow Management | Business Transformation | Enterprise Agility | Business Growth, Performance & Innovation Leader
Golden Nuggets, Honest, Unbiased Thinking, Opinion, Entertaining Long Reads and Mini Guides of Practical, Pragmatic and Shared Know How from me as an Agile Practitioner to help you Accelerate your Journey towards Enterprise Agility.
EA Silo | Agile Manifesto | Legacy Modernisation | Uplifting Architecture | Agile Architecture | Canvas | Playbook
Enterprise Architecture & Strategy Units/Departments get a bit of bashing because of their perceived Archaeological Approach and in some cases, actual laborious and bureaucratic processes that sustain the legacy over IT Modernisation of EA and Business' Architectures and Capabilities.
I m here to put help put the Agility into the A of Architecture so we can all play collaboratively and co-create experiences.
Enterprise Architecture gets overlooked in Organisations making the leap toward Business and Enterprise Agility. Its seen to be part of the skillsets of Agile Product or Solution Delivery Teams, therefore, they become laggards in the race to get every team/dept up to speed with Agile Practices, Culture, Thinking and Ways of Working.
EAs are more akin to Enterprise Change Agents, Strategists than there more technical SAs and TAs brothers and sisterhoods.
…Agile Starts where Enterprise Architecture Ends…
No matter your views, experiences, opinions or perhaps onions because EAS just makes you cry revelling in its power plays, bouncing you back and forth with “No’s” and ITIL or COBIT process on top of TOGAF, however, it’s still really important to enable Team and Technical Agility, Business or Enterprise Agility, the creation and Flow of Value, so its worth the rescue effort to realign or bridge the gaps.
In this article, I want to deep dive into how to bring Enterprise Architecture to Agility and Agility to the Enterprise Architects Roles and Domains by looking at the customer expereince pain points of EAS and see how we can get them back in the game, playing a key role in our Agile Delivery Systems, Business Systems and Journey’s to Agility with my Enterprise Agility Coach, Agile Consultant and Transformation Lead hats on.
Fun Fact: Did you know the Open Group are working on an Draft Agile Architecture Framework Standard?
Rainy-Day Stories and Pain Points of Architecture and Strategy Silos
TOGAF, Zachman, NIST, Domain Driven Design….there’s more Enterprise Architecture Models out there.
Every Discipline bases themselves in Theory, it’s the foundations of all practices, however some are just better at being more pragmatic, practical and practice by doing.
Architects, EAs, SA, IA’s TAs all talk about abstraction, but you can never seem to understand how much abstraction is the right abstraction as they play with you conceptualising and driving you mad with use cases you don’t know, care or understand.
Architects say “No” a lot without explaining themselves, computer just says no, rather than being masters of change management, in dichotomy to what they should be doing, progressing the enterprise, not defending their patch or empires as dark arts, in secret clans.
Architects are blockers, impeding progress, as they get concerned over whose budget, how much it will cost, who will pay, despite business owners, managers, depts and PMOs/APMOs asking them for Technical help, not Financial Advice.
They love a good ticketed or multi stage process, whether its ITIL or COBIT lead or using Design Authorities as the Dungeon where you get to face off the power of the Dragons and wait 4 -6 weeks between rounds.
And they build this all in too add complexity, rather than aid flexibility, be adaptable, open minded, trusted advisers and practitioners who herald in change and transformation, slowing down Business or Enterprise Agility.
The Sunny Day Story
The upshot of the Dungeons and Dragons is what they do well, what a good Architecture Team, Architect can and do and do right to our advantage is:
They stop Agile teams just doing activity without any discipline towards the what, how when and why they should be aligned
New Skool
The days are numbered, good CIOs and CTOs are dragging Architecture out of the black holes and aligning them better with the business under a new management approach – Business and Technology Management, BTM, trying to get more from both sides, both being equals in driving business performance and value as customers and clients of each other.
Architects themselves are also modernising themselves too, so its not all doom and gloom as they have realised the days of long-term business planning is over in the Digital Age, Enterprise 4.0, Industry 4.0 and for the Post Digital era.
The Traditional 3 Pronged View of EAS
The traditional standpoint of EAS is the do 3 things from its process:
Herein lies some of the problems and opportunities too.
In the VUCA, we can’t plan in annual, 5 -10 years cycles. How many of the FTSE or Global 100 are still around from 20 years ago, 10 and even 5 years ago, like Dinosaurs, they have died, become extinct, by the fast pace of evolution and revolution.
The old Business Systems and Strategic Planning Models and Processes are dated and based on command and control theory of by gone era.
Standards mean slow, bureaucratic process, heavy handed governance and lots of saying No.
And you need to fit into the Agile Solution Design and Product Delivery “standards” the rest of the Team are using to work faster and drive better business and customer outcomes.
I am doing this in a kind of a Johari Window approach, looking you in the mirror to realise how your perceived in your functional silo, intended or not to the recipients of your messages, communications, and management styles and even victims to your own Organisational Design and Structure e.g. the Business Architecture
The other aspect to this and things like TOGAF, love it hate it like Marmite/Vegemite, is that’s it too inwardly looking, hence allowing the disruptors and disruption through the door all too easily, so whilst you got your internal business landscape view sorted, you’ve got business people yelling and screaming to get this new shiny stuff and that thing - the thing that our competitors has, (a conversational AI Chatbot on their website) to fend off the competition or being the game, instead of infront.
EAS From an Agile Manifesto Point of View
Now to get the Agility into Architecture, I need you to look through the lens of the Agile manifesto.
The key outcomes of EAS should be to:
Continually Deliver working Software, Solutions, and Capabilities over comprehensive documentation
Value Individuals and Daily Interactions over standard processes and rigid tools to maximise customer Value Align Business and IT Value Streams and Portfolios
Respond to Change over following set plans, set and model-based designs
And to collaborate with customers over contract negotiation, leaving that up to your Agile Legal and Procurement team and folks, guided by your input and Portfolio Leads to worry about budgeting and funding it, resetting your expertise to where its most needed – focused around business and enterprise organisational change management
How to start doing this and stop doing the above, is at the core and why I use the Lean Business Canvas concept, adopting it to create the Lean Agile Enterprise Architecture Canvas as well as taking the BCS’s EA on a Page idea to it, to align it to Agile Ways of Working by further reducing it to Minimum Viable Answers to EAS questions, basing 40% in EAS and 60% in Scaled Lean Agile Business, Enterprise Development, Product Delivery and Agile Change Models.
A Few Other Pointers/Top Tips:
Agile Architecture is missing from the Agenda of Scaled Scrum Methods
The Official Online Scrum Guide – were all newbies to Scrum see to go these days doesn’t talk about Architecture, Agile Architecture, Strategy, UXD or Lean UX Design at all.
Scrum is 25th years old and a new 2020 Scrum Guide has been released this November.
Its dumbed down even further now, supposedly to open up interpretation to more than just software development.
Its now only 17 pages not 20, misses out key and basic guidance like the 3 basic things to structure an effective Daily Scrum, around and for those that now,
Scrum looks basic, easy but its hard to master and scale well, if at all
Under the PO and SCM sections – it fails to talk about how Architecture and Strategy is key to building a high performing Scrum Team. It says they should remove impediments, but one of the big impediments to teams delivering is the Blocks and Barriers they can find in the Architectural Runway/the EA Strategies and Capabilities of the Org preventing them using a new Technology, a new coding language, a new tool etc.
It also says the PO and SCM should not let quality slip – but how? It doesn’t even point to the concept of Built in Quality, so how do new comers know this? Adding a Why question over What for defining the Sprint Goal and Planning I don’t think is enough to overcome the many gaps and deficits, a making one new reference to Lean doesn’t make up for it either and traditional PM, Product or Software development doesn’t help with the transition and gaps in knowledge and understanding left here.
Scrum Artefacts include the Product Backlog, Sprint Goal and DoD, so I assume an Architecture Sprint and a Design Sprint ( or Spikes as some call them) or Sprint Goal must be used as the answer – but 4 huge Anti-patterns that exist and still aren’t plugged are:
The exception to these only exists when Agile Teams or Agile Org’s adopt Scrum XP, otherwise they pick the easiest low hanging fruit that will fit into the Sprint – Activity over Alignment to Purpose.
The Scrum Guide Again isn’t helping Agile Architecture Disciplines, Domain Practices or Agility.
What I take away from the declining Scrum process, e.g. each revision/update to the official guide, is that its just becoming:
More and more of a Team Leadership Model like Tuckman’s Forming Norming Storming, Performing
over a light weight, incomplete Agile project management method that’s got lighter, weaker, and more incomplete each time – the founder argument is it just getting less prescriptive.
Adding to the 4 Anti-Patterns above, I am going to predict a new one, old really, but it will become more ubiquitous and pervasive now.
The term “Development Team” has now changed to “Developers.”
They justify this in saying they want to avoid having a “team within a team” that can lead to an "us vs them" antipattern.
You used to have the PO, SCM and the Development Team. Now you have the Scrum Team which includes the Developers, SCM and PO.
I think they have stuffed up here, trying to take the DevOps end to end “One Team Approach” and use it in Scrum to try and say they can create and focus on delivering value as a single team – a team that only has “Developers” on it. WTF?
This is Agile in Chaos…trying to please everyone, yet no one, to save and extend the life of one product, one team Scrum.
Scrum Team Typology and the missing “Architects”
The typology of a Scrum Team, for software, product, service, marketing whatever, was it was made up of cross functional, multi- disciplinary team members, all complimenting each other to get the job done.
This is now missing – therefore I am arguing, so is Architecture and Strategy as you lot aint “Developers” (or do we interpret than loosely and even more woolly to mean, Product Developers, DevOps Engineers, Solution Architects are developers because they develop stuff)
I noticed in the PDF version, it kept cross functional and this has been added to the online version too now, however, it still focuses into just software development and Scrum is used much wider than that and that seemed to be a goal of dumbing down again, not simplifying, the Guides.
Nexus and S@S Scaling, Not Failing Fast or Forward Either
As a Enterprise Agility Coach, Agile Consultant and Transformation Lead, I am always inspecting, adapting and adopting different things in my toolkit, through a critical lens for success but I am feeling Scrum, as I said before, is really in its end of life phase.
Scrum @ Scale fails to integrate EAS as it uses them a specialist Shared Services, keeping them in a silo and drawn out only when a smart bear has the nonce/nowse to do so or by mistake at a SoSoS, EMS or EAT rather than by default integration and appreciation.
Nexus or Scrum Professional Scrum’s Integration Team allows for different people at different times, so adding some pragmatism and flexibility over Scrum and S@S atleast, but still not enough.
I’ve searched docs, the official 12 -19-page guidance and course notes and there are no references to Design, Architecture or Strategy in there, amplifying the Scrum Guides issues to integrating this discipline and its domain areas.
There so called “Scale free” Architectures are the least best one’s to emulate to rebirth Enterprise Architecture to the fore of the Agile Enterprise
Scrums Mantra has been “Delivering twice the value at half the cost”
I don’t believe it can alone anymore, its now just a small cog in the bigger wheel of Business or Enterprise Agility and for that matter, Team Agility as well as we have moved on to more modern, context specific adoptions and interpretations of Team level Scrum in Scrumban, Scrum with Agile, Scrum XP to plug the gaps they fail, don’t want to or aren’t interested to fill and where EAS can play a bigger, integral role.
The Playbook to Bring Agility to Architecture and put Architecture into Agility?
1. Invite them to have a Seat at the Table
I am all about MVBs, less formal meetings, less paper shuffling etc, so its critical that we give EAS a seat at the bale rather than shun them and say your yesterdays news, as they are not.
Empower them as part of a Self-Governing, Self-Organising, Cross Functional and Multi-disciplinary Team, you’ll have to teach and show them this the hard way, but once they adapt, they will be useful folks bringing Domain Knowledge, Repeatable patterns, and strategy knowledge to the Portfolio, aligning Teams to the Business and Enterprise
They will be able to see problems and all we have to do is Coach and Mentor them away from the Fixed Mindset, Saying No and Command and Control style infused from ITIL and COBIT governance and control thinking etc, getting their glasses half full and looking to be innovators, game changers and internal disruptors as part of the Agile Team running the One Team DevOps OS not Functional Silo OS.
2. Agile Conversations, Coaching, Labs and Dojo’s
Continuing from above, Architects are humans, humans are complex beasts, so open them up with face to face dialogue to build them into your effective, high-performance teams.
A great way to do this is 1:1 and in small groups among peers using a Dojo format.
The goal of the Dojo should be to learn, respond to new information, building trust and internal commitment by surfacing issues in the room
Recommended by LinkedIn
The as the Dojo facilitator, you’ll need to use the 4 Rs:
And in between switch it up/do role reversals and change the scenarios, to keep it both interesting and participants on their toes so they don’t game it, take them across the ladder of inference and then decode it and make an action plan as ther EAC to get involved in the Agile agenda to support it.
Set up at least 4 Follow Up Coaching Sessions 4 weeks apart as part of the Coaching Contract to make it real and make it stick.
Labs are also a great way to do Immersion Style activities, introducing people to Tech Use Cases, Solutions, Spikes or Venture Capital/Google Style PoC or PoT Sprints.
3. Evangelise the Benefits of Agile Architecture
This one is on you Architects.
You need to show leadership, you need to show skin in game, you need to help others see what this is so important.
Review your NPS, Rating and Reviews, KPIS and Metrics o how well your perceived/taken.
Conduct an Internal Roadshow.
Set up some Internal Webinars.
Form an Agile Architecture Community of Practice.
Tell us how your going to decouple spaghetti junctions, bring in event driven SOA, use containers, promote self service and everything as a service thinking, how your going to openly share the Ref Architecture and Capability Maps of the Org with everyone so they can see what we have and don’t have. Cloud First, Mobile First, DevSecOps…there is so much to offer, engage, interact and built team connections, integration and support and move from pain in the backside to trusted partner status.
Measure again and uplift those scores.
4. Select LeSS, DA or SAFe as your Delivery Frameworks over Scrum
LeSS , DA and SAFe, all promote Architecture, Strategy, Architects in Teams for Solutions, Products, Services and Platforms and as inherit and explicit parts of their Business and Enterprise Agility agendas.
This shouldn’t too hard to achieve given you’re the master of your own destiny’s already and all you have to do, is abstract and see how the LeSS, DA or SAFe overlays your Org Structure, hopefully its already a matrix one, and pushes you towards even more Org and Team Agility.
In order to do this, you’ll have to give up some bad habits learnt from ITIL, COBIT etc, eg give up the centralised DAs, CRs and CABs and go to direct to the teams Spritn Planning, Reviews, Big Room or PI Planning events, but don’t throw them out completely, just adapt them to be more Agile which ITIL is trying hard to come to the table with as they are complementary knowledge to support flow in all these approaches.
5. Open up your Enterprise Architecture (EA) Tools
Have you got LeanIX, Sparx, BizzDesing, Qualiware, Planview?
Take a leaf out of the Enterprise Agile Planning, Agile Product Management and Collaboration tools and:
The tools with help Business folks and IT stakeholders with strategic planning, analysis, design and execution, strategic and tactical decision making by capturing, connecting context and sharing information across the business, information, solution and technology domains to help with planning and executing business strategy.
Let Developers see what tool they can put into their CDRA pipelines, ow they can integrate security and testing, how marketeers can reach audiences in channels, how the plant equipment and IoT devices can be updated by APIs at docking points or through no down time or over the air updates.
Hopefully you aPaaS or SaaS, so can do this by using a read only view/privileged access and don’t charge back as IT is a service to the entire business not a profit and loss cost centre.
6. Build Up your Inner Sourcing Capability for Reusable Assets
Stop paying out
Stop outsourcing
Reducing the use of Systems Integrators
Start building your assets up initially using a CoE moving towards a Self-Service Platform
You all now what Open Source is, how it works, so start Inner Sourcing
Sort your web services out
Implement a White-labelled First Policy
Containerise them/Dockerise them
Make them available in a Repo/Libraries in a self-service way so Dev’s can reuse them by configuring or repurposing as opposed to starting from scratch.
This should be part of your repeatable patterns approach, so it will save cost, save time and rive sped to market through reuse, repurpose and scale.
Its key to sort out any IP issues as to get this to fly, Devs will want, and deservingly so, to get the kudos and credit for their work, so use creative commons and other means to keep Open but Inner Sourced.
7. Run or Join Facilitated Workshops and Visual Thinking Sessions
Agile Folks are loud, noisy, always sketching, thinking, designing, talking to each other in an good way and communicating at stand ups or offline in their pods or with others around the business.
They don see hierarchy, they have flat respectful, collaborative, and sharing relationships and don’t take well to exploits of power, position, or status.
Emulate this behaviour and activity in EAS as part of getting your Seat at the Table.
Facilitated Workshops share power, share leadership, decentralise planning and decision making as they are consensus driven, trade off based building technique.
Traditional workshops are directed and more like telling sessions perhaps with a litel activity thrown in for good measure, usually and ice breaker at the start and a poll at the end.
Facilitated Workshops focus on bringing the teams of people together over the experts.
You will build that trust well-facilitated session run or joined into, by doing more listening, more quality assuring, guiding in the right direction and into alignment through your interaction and not coercion.
Another great aspect and fit with Agile Ways of Working, is that they are timebound to extract OKRs, as opposed to document-based approaches when combined with Visual Thinking so they can be written as Story, or done as Spike or Set as a Sprint Goal.
Visual/Spatial Learning or Picture Thinking is a far better way to do Design work – both Architectural, Strategy and UX.
Because Whiteboarding, Sketching and Drawing POAPs for Network Diagrams, Data Flows, IA, App or Tech Arch, like Mapping Customer Journey’s, are interactive and creative, you will align yourself to the Agile Ways of Working of the Team you’re trying to Engage in, Collaborate with and become a Trusted Part of.
You can start these off from brainstorming sessions or mind maps and build them into a full on Architectural Views or more business and user friendly half way house formats between traditional Architecture, again, earning that spot in the team, climbing their respect ladders and trust equations.
8. Use my EA Canvas
To run or join in Facilitated Workshops and Visual Thinking Sessions to Create and Support Lightweight Agile Governance, Controls, Guardrails and Lean Documentation, you can use my Enterprise Architecture Canvas below:
This is a Strategic Lean Template/Visual Chart/POAP you can inspect and adapt covering off most of the EAS needs whilst being able to make compromises and trade-offs with agile teams, programmes, Trains, MetaScrums, SoSoS etc.
This format has worked well at Big Room, PI planning events, for Spikes or Arch or Design Sprints to Hi Fi and LoFi Whiteboard Modelling Sessions.
It will help you create, align and model all the Architecture Artefacts surrounding Rules, Structures, Changes, Considerations, Standards, Landscapes and Designs in a far quicker and more palatable way to Tech and Non- Tech Audiences who are you customers and clients of your EAS expereince and more so, who are wearing Agile Hats and Being and Doing Agile.
9. Write Architecture Stories into the Backlog of Agile Planning and Collaboration Tools
Its sound stupid, but I want to modernise you and bring you into the fit, culture, and modus operandum of Agile Teams, so Write Stories.
Stories are the Agile Way for doing Requirements, only better as they are 100% customer/end user focused and not the vanity projects of the HIPPOs.
If your working in DA, Less Huge or SAFe, then you have a treat install for you.
DA uses the Agile Enterprise Architecture Process blade and has great guidance on how to build EAS in.
LeSS Huge uses Stories, Requirements and Development Areas and also has great guidance on building EAS in.
SAFe uses Enabler Epics, these come in the form of Architectural Epics - to build the Architectural Runway for smoother and faster development and have Enabler Features and Enabler Stories with their SAFe Requirements Framework all tied into Development Value Streams in ARTs or ST aka they two type of Trains.
So remember how I said about partnering/pairing up with PO, SCMs, Tech Leads, RTE etc daily….Yeah, this is why.
You can get Architecture Enablers, Process Blades all into Stories and onto the Backlogs of Teams, Programmes and Portfolios, including the IT Portfolio and get them Prioritised because you’re a Trusted Partner to the Teams and your collaborating to get maximum value delivered, in alignment to the Teams, Programmes, Portfolios and the Business.
It doesn’t end there, you can now actively participate in Sprint Reviews, Demos, Retrospectives, PI Planning, Big Room Planning, Meta Scrums, SoSoS with your Seat at the Table, earned and owned!
And, you have co-created architectural artefacts in the Teams wiki/knowledge repo/run book/playbook as well, building in quality, technical excellence, adaptive standards all with flexibility and not the rigidity of TOGAFs 20 principles, ITIL, COBIT and other staged/phased/gated process driven, commercially monetised approaches.
Being the Agile Architect and Doing Agile Architecture
The be the Agile Architect, draw upon all your expereince that of your peers and the Teams you work with – building Trust, Respect and Rapport as we don't want to be in this position:
Share openly and transparently, your EA Vision and Roadmaps, showing the path in 30, 60. 90, 120 and H1/H2.
Offer direction, offer guidance, and practice enablement, don’t set technologies, tools, and solutions, empower the team, and allow evolving and emerging architecture supported by technical excellence to come to the fore.
Invite exploration, experimentation and testing and learning over rigid set-based designs, monolithic applications within guardrails and not standards.
Drive reuse, patterns, and practice to maximise value by alignment not power and control.
Don’t assign responsibilities, let the PO or SCM be the bad person, trust the team, let them pull work and co-create and collaborate with them.
A great way to introduce yourself and the EAS team in by way of a Charter.
The Charter should set your first principles, mission as to why you exist and how you co-create, collaborate, and consult with your clients and customers.
An Infographic Slide/Poster/Visualisation is a great way to do this so it can be shared, put on Portals, Wikis/Repos, Intranets and into Culture Decks for Onboarding new Talent etc.
Lets wrap up.
Conclusions – putting Agility into the A of Architecture
I loved Scrum, I still do, but I am falling out of love with it each time I see a revised Guide and people talking it up, talking shit about it and because of its general regressions.
It was one of the most innovative things that created a lot of the foundations for both the Agile Movement, Agile Methodologies and Agile Scaling Frameworks based upon it.
As someone who tries to be agnostic, non-binary and super pragmatic in helping Team, Orgs and Enterprises go on the journey to mastering Agility, it makes it super hard not to say Scrum has passed Maturity and is in Decline, therefore I am more inclined to recommend DA, LeSS and SAFe as a more holistic approaches to all levels of Agility to rebirth EAS, even though they use One Team Scrum and Scrum XP in their basis and options for Emergent and Evolving Agile Technical Solution Delivery.
Don't however, go off and think you need to reinvent the wheel with your own method, framework or process, just inspect, adapt and optimise what we have got, when you do, it works!
Finishing where I started, trying to get Agility into Architecture and Architecture into Agile to get better business outcomes, better alignment between portfolios, value streams, business and enterprises to surprise and delight end users, stakeholders and shareholders, please inspect, adapt and try my Enterprise Architecture Canvas – it’s a game changing visual tool for shifting mindset’s, thinking, practice, process and culture and DA, LeSS and SAFe are better choices to give EAS a Seat at the Agile Table.
Last Laugh....such an old fashioned thing to do right!