For as long as I have been building Iasa and working with architects, architecture teams and their stakeholders, I have been amazed at the lack of rigor and structure in our work. Not amazed in the good way, but more ‘How the hell do we get away with such variable competencies and methods?’ sort of way. I mean if medicine or engineering were as variable as the work we do, there would be a LOT of unhappy people in the world… buildings collapsing, magical formulas applied to broken arms or eeeek, surgeries.
This is my real quest in life and why I am still going with the architecture profession 20 years later. I want to find the science of our practice. The repeatable conceptual steps that allow architects to come to similar answers based on similar context and need. Also to find the commonality and connection between differing ‘types’ or specializations of architect.
The key to this quest has been finding conceptual linkages between the competencies of architects and the concepts they use which flow properly together. To illustrate this point think of a business architect and a solution architect (in this case lets imagine the solution architect is primarily complex software focused… or by our definitions a software architect). We can get into the difference between titles, functions, competencies etc in a separate post.
Now our two architects are focused on the same value stream and a large solution being deployed. Let’s call this a sales/retail solution for a large retailer. Lets make Joe the business architect and Jane the software solution architect. How do their competencies overlap? How do they work together? How do their deliverables interact? Iasa does a large number of corporate assessments and evaluations of maturity for architecture practices and the answer in most seems to be… they don’t work together well at all. Joe is off creating capability models, strategy scorecards and business model canvases and Jane is doing detailed technical designs, devops and product owner coordination. Both have a massive number of shared stakeholders and both are describing architecture as a completely different activity to them. It is confusing and not at all focused on success in creating a comprehensive, structured way of delivering architecture at the value stream and large solution level.
So this is why I’m a huge fan of our Structure Canvas Approach (again Structured Concept Approach is more accurate though we do have cool canvases :-)) This is the primary method we teach in our Core Class… all the way from foundation level all the way through mastery levels. It creates a set of connected concepts that are easy to repeat, require low levels of maintenance and connect the work of architects together. The following shows some of the canvases we teach in Core.
Notice the connections between items. These connections are not static, meaning they represent possible leaps between concepts… like the business model canvas and customer journeys. And their are connections that aren’t documented here. For example customer journeys are heavily interesting in roadmapping and service blueprints in context designs. For example the canvases can be configured for decision making as follows.
Notice how many ‘business’ artifacts are absolutely essential in even the most technical design? This is why the Iasa method requires all architects to have both business and technical skills. Imagine a world where business and solution architects worked effectively together as apart of the same practice (hmm just like doctors with different specialties).
This is the real strength of a formal and working engagement model. And it serves as the basis for our Core classes and Associate classes. It is why Im in love with the Structured Canvas Approach and why you should start looking at it very seriously if you want to run a modern world-class architecture practice.
Register for our upcoming Architecture Core Course starting July 13th online at: https://www.iasaglobal.org/Public/Events/JULY-CORE-COURSE-ONLINE.aspx