The function of Enterprise Architecture (EA) is critical for medium to large organisations – and irrespective of whether you agree with that statement or not, EA is an established movement within the industry. But where does (or should) EA sit? In the waterfall world it’s very clear where they sit but what about within an Agile cross functional team? Do you simply replace the shiny ivory tower with a tower constructed from laminated index cards? Should all architects code? How much up front design is enough? What do architects do anyway?
For many years I’ve observed a tension between Enterprise Architecture and Agile. Many of the questions above are often touted in an attempt to rubbish or undermine Architects as they go about their normal day to day box drawing and navel gazing activities 😉
In the diagram above I’ve tried to illustrate a simplified view of what a Kanban system may look like, but augmented it with common sources of demand and feedback loops. Another important column above is the NEXT column. This is the column that drives powerful conversations on what should be selected next. What’s more important – implementation of a new centralised logging service? – Deadline bound changes in response to new legislation? – Paying off some Tech Debt so we can go quicker? – That new sparkling feature “guaranteed” to reduce drop-out?
Sources of Demand
Architecture – Leffingwell uses the term ‘extending the architectural runway’. As your core product evolves based on analysis and feedback from customers, an idea or requirement may be raised in the product backlog which requires a significant investment of time and new skills. As an example, if feedback from customers is “stop bombarding me with pointless ads on your site” the requirement might become ‘We need a single customer view so we can do personalisation’. To implement this may require interfacing to an existing CRM system or even the deployment of a new ‘strategic’ CRM system. Once this enterprise component is in place (and thus extending the architectural runway) product teams can consume this new organisational capability. The feedback loop for architecture can be augmented by live site monitoring which provides insight into product health along with many other NFR’s which in turn feed into Architectural decisions and planning.
Unplanned Demand – One of the biggest flaws of traditional portfolio management is that I’ve still to this day never seen any capacity reserved for the unexpected. When I ask PMO folk “Great looking plan for the year but what about unplanned work that WILL crop up?” I usually get that vacant look as if I’m talking a foreign language (common problem for Rightshifters!). Here’s some examples of unplanned demand that can crop up: Changes to the Consumer Credit Act resulting in many changes for some eCommerce sites, European Cookie Directive, discovery of security vulnerabilities in core platforms. What about if your competitor catches you off guard with a new website feature – how many times have we all experienced a knee-jerk reaction from CxO’s in response to such things??!
Tech Debt – I hear a lot about Tech Debt across teams. Very few teams visualise it, even fewer understand how powerful it can be as a negotiable project attribute. [Future Post]
Proposition Demand – refers to the core purpose of the team. An example could be the development of features for an ecommerce site. This demand would normally manifest itself on the board as a set of tasks, stories, epics, MMF, MVP, or whatever you use to describe the work to be done. These could be tactical or strategic work items. The objective here is to get rapid feedback on features released using analytics or gauging Customer Satisfaction. This feedback can be used to stimulate the product backlog, or if needed, feed into an EA team to extend capabilities. Why not use a coloured sticky on a story in the backlog to indicate it’s blocked until the architectural runway is extended?
In my next post I will show you how one team of EA’s visualise their work.