Ten Principles For Great Architecture

10 Principles For Driving Engines of Value

The single biggest issue facing business and technology today isn’t technical debt nor is it digital transformation nor is it agile. It is the age old problem of designing and delivering sustained innovation at the core of change — the delivery team. Doing this at scale will accomplish all of the other items without a top-down approach. All of these techniques are taught in our Bootcamp/Core/Solution courses at different levels of depth. In addition Iasa works directly with corporate members to assess their maturity and co-design engagement models which accomplish similar things. 

High Quality People Top Any Other Technique By Far: This has been my standard soap box for over 15 years and it isn’t likely to change. No technique, process, tool or training will overcome having poorly skilled, and underpaid staff. Nothing less than technology excellence keeps the modern business running including more and more small businesses and so staff are already hard to come by, much less highly skilled and capable staff. At some point we as a group are going to have to realize that the days of the generalist under-educated expert are over. The world needs a systematic way to populate its technology roles and create a highly capable workforce. This has to start with STEM education and must include rigorous role/experience gathering. Getting your first architect job should not require 10 years of experience it should start with accredited and managed internships straight out of university where you are guaranteed to get experience in all competencies in the 5 pillars. This career path should require rotation based experience in business, information, infrastructure and software so that we can begin to fulfill our skills shortage instead of continuously making it worse.  

For the time being your organization should formalize its technology roles and their interactions and begin increasing their general skills training as well as implement the Iasa mentor-rings system. Along with continuous experimentation you will end up with a much more powerful internal workforce. 

Get the Right Architecture Artifacts at the Program and Team Level: I have found the team needs the following business and technical outcome tools to deliver value: Business Model Canvas, Customer/User/Employee Journeys, Capability Canvas, Service Blueprint(s), Roadmaps (Sankey Diagrams or Roadmap Canvas), Business Case, Context View, Benefits Realization Views, Decision Repositories (Cards), Delivery Communication and Epic View(s) – these are deeply variable based on product, Benefits Utilization Repository (Cards), Product Change Retrospective(s). This set of elegant and relatively simple artifacts seem to be able to guide even the most sophisticated products. I am doing blogs on these and will be teaching the Core Course (Amsterdam April 6 for open enrollment) which covers each in depth. Iasa has or will have a post on each of these elements and techniques for working as well as ‘learning shots’ for their use within the ITABoK. For examples check here https://itabok.iasaglobal.org/learning/ for understanding the Business Model Canvas and Customer Journey. 

Perfecting Solution Value Comes Before the Enterprise: Most organizations drive change from the top down, which is understandable given that much of the outcome focus for an organization is driven from the board and from market demand. However, top-down transformation is fundamentally impossible. Transformation is cellular. Imagine the enterprise as an organism or an ecosystem. Change happens at the person level, and all other is process, and bureaucracy. 

Instead focus on perfecting team dynamics first. Healthy tension, what I call the proper layout of roles and specializations within a team, will fundamentally alter the outcomes of the team. Development Leads are NOT architects, nor do most of them want to be. They want to write good structurally sound code, but their focus is ‘down and in’ on the product not ‘up and out’ on the enterprise technical and business outcomes. Product owners are NOT architects. They are focused on the ‘up and out’ but lack technical skills to make value trade off decisions. 

Once you have this method 70% perfected, duplicate it 5-10 times. Once you can work it that many times, scale it up even more. It will take you around 12-18 mo to hit enterprise scale and scope and by then you will have so much support you wont worry about resources!!!

Architects Have to Say No to Be Able to Say Yes: There are always too few architects compared to the work at a company. We are a scarce resource. Based on our information the average company has less than 1% of its IT footprint as architects. This leads to architecture as an ivory tower or as a governance community. It also means that architects are not able to be proactive on product/service teams as there are simply too few of them. In fact our basic finding over the last 10 years or more has been that architecture doesn’t really begin to get full results until it is roughly 5-6% of the IT footprint in an organization and more if they are heavily technology dependent like banks and healthcare. For architecture being reactive and governance focused is sure death (the team will cycle between two to three years of success and two to three of ‘failure’). That means architects need to changer their approach in this scenario. Instead of trying to cover 100% of the scope of the enterprise they need to narrow down their contribution to be proactive, delivery focused and value based. This means saying no to the right things so they can say yes to the right things. 

In our training and corporate member work we spend a great deal of time on how to do this as blanket nos are as bad as blanket yeses. We recommend a heavy focus on the investment planning portion as well as heavy focus on time management. But as long as all the architects are on value delivery it is easier than it sounds… “I would love to help you ‘put out that fire/work on that project/build your capability’ but I am swamped on the new retail system for the CEO, we need to hire more architects for us to cover that”, is pretty hard to argue with. 

Continuous Experimentation Is Continuous Learning: To be an architect, is to continuously learn. That is true in all fields and especially technical ones but architects in general are always pushing themselves to learn something new. But to really learn you need to be trying things real world environments and not just technology. In the core class we teach continuous experimentation as a means of team and individual learning. We do a mix of experiments in business, human dynamics and technology and use these as a tool for measuring team performance. You can download the card here. And here is the image for you to review. Notice that each experiment is roughly 2 weeks long (any longer and it becomes a prototype) and we do about 15 of these experiments in class.  

Valuation Skills are Enough to Tell Velocity From Value: Velocity numbers in agile make me think of time to market, budget and resource usage as the traditional measures of IT success. That is decidedly old-world thinking. Velocity of delivery of functionality can make a few users happy while sacrificing value to the whole team or organization. That is inevitable as things go in complex systems like an enterprise of people, process and technology. But while you may have continuous delivery pipelines and one touch deploy and beautiful unit and integration tests, wooo hooo, you just guaranteed you will be able to get your next job in IT since that is how we hire. And you are going to need it, since you spent your time on that instead of business outcomes you can measure in revenue or customer success or operational outcomes and sorry but the team is being shut down due to lack of real delivery. Ok ok I’m an old curmudgeon. 

Value language is addictive and changes the nature of delivery in near magical ways. I don’t mean one value algorithm to rule them all, like ROI or TCO, but instead a layered approach to value comparison all the way from value themes similar to what Mike Cohn describes to simple option opinion polls of dev teams all the way to business case proposals to internal investment teams and value repositories. Using these techniques, which Iasa members have helped pioneer through the last 15 years, will open up your decision making and make Agile and Dev Ops adoptions significantly more successful. Combined with value capture techniques post delivery this becomes a near-magical technique for guiding decision making. 

Velocity and Stakeholder Success Are Different: A stakeholder driven architecture approach is one of the first goals in the Iasa maturity method. It moves us from a cost driven governance model to a value outcome delivery model which is the only way for an architecture team to mature. You will find quickly that value and velocity are not the same. Value delivery is about achieving measured outcomes that show real improvement in operations, revenue, or capabilities. High velocity/low value delivery does nothing but waste money. 

Here are a couple of our stakeholder management cards which you can also download here. 

The power-interest grid aligns your stakeholders to their interest in you work. 

The stakeholder ecosystem canvas helps you understand the relationships between your team and the stakeholder community. 

The stakeholder empathy map will help you get in the minds of your high interest/high power individuals and understand their real outcomes. 

If You Are an Architect, You Have to be Both Technical and Business(y): It takes a long time to create a business and technical generalist with enough experience and learning to be considered an architect (certainly an Iasa architect). How much ‘technology’ is enough? How much ‘business’? Can’t we just have business architects that don’t really know ‘technology’ and technology architects that don’t really know ‘business’? This question is something like a ‘3rd rail’ in architecture circles. I piss off conferences regularly by saying sorry, but no, you cant have a senior architect without reasonable depth in all 5 of the pillars (BTS, IT Env, Des, QAtts, HD). Put whatever you want in front of it (Business, Solution, Information, Infrastructure, Software, Azure, AWS, Application, Data, etc). While they may succeed for a period of time within a particular organization they will ultimately face the ‘Value Challenge of Architecture’ and will fail it in some way and are definitely not easily transferable to another organization. In addition, they will continuously focus on battles within the global practice of architecture until one group loses by ‘winning’. This will set the practice back by 2-3 years. Instead having a group of architects with strengths in the five pillars allows for large teams to specialize in much the way medicine does and without risk of infighting and value challenges. This too has been the subject of many of my posts as it really is the single greatest risk to an architecture practice over 10-15 people. 

You Should Make Innovation 70-80% of Your Focus – Governance Doesn’t Pay:  My friend Gar Mac Criosta (pronounce it like you are a pirate, he loves that) likes to say, “Architects are the only role in the company that gets paid to slow down something everyone else wants to go fast.” I tend to agree with the caveats above. 

I have watched architect teams try and try to keep the company from making bad decisions for 20 years and invariably over time they are not only frustrated but devalued for trying. There are simply too few architects and too much enterprise and stupid people make stupid decisions no matter what you tell them. Governance is primarily about risk appetite and it is a Cross-Functional Responsibility not a group of super humans (note I called architects super heroes there J) trying to keep a ship from sinking by swimming harder. If the organization needs to govern itself, the process should include architecture but as an equal participant with other technical roles. It is either a shared responsibility with clear organizational consequences or it is a non-starter. Architects should be governed not governing.

The best ways for architecture to feed a governance approach is to populate it with a) effective roadmaps, b) value based decision making, c) principles and building codes that are effective at the team level, d) bottom up participation at the product and team level, e) equal participation in governance consequences, f) effective cross-team product collaboration. There will be another post on this topic coming soon. 

CAIDOITAB is a Perfect Stack, Except When It Isn’t: Cloud, Artificial Intelligence, Dev Ops, IoT, Agile, Bots are here to stay, with only some question left about the scope of impact of AI, Bots and IoT left in question. However, most organizations are not really ready to handle all of them. Your organization is not likely Google or Amazon or Apple, it has its own maturity and readiness and no one size fits all. The push to this stack is driven by technologists who all want to work at Spotify and Microsoft. We are a terribly hype addicted crowd (me included). 

First, some organization’s value streams are not well aligned with this approach at least initially. Companies like Bosch and Transavia have made successful inroads to large scale adoption, but much of the worlds organizations are simply not able to make the case for the switch. Focus instead on making high quality decisions about approaches to each of these using success cases which can be repeated to build momentum and culture change. Also keep in mind, NO ONE wants to fly on an airplane designed on a whiteboard in a two week sprint. Many times safety and quality attributes are equivalent to functional value outcomes.