Embracing Software Architecture

The whole concept of the BTABoK is to help architects either to make their jobs easier or to expand their competencies and surpass their current expectations. This is very important in software architecture where there is significant confusion around the difference between a software architect, software engineer, developer and a specific technology expert (vendor or product specific). This document answers that according to what we have found in evidence and attempts to clarify the tools in the current BTABoK for the software architect and their stakeholders.

Join me on March 18th to explore these and many more topics in the 5 day Core Masterclass in Amsterdam! I will work you very hard, but it will be worth it... If you can't make that date, there are dozens of other opportunities and courses around the world!

Coming Full Circle

In many ways this was a full circle journey both for me, the author and CEO and for the Iasa which started out before there were too many types of architecture in common use. Chief architects, enterprise architects, business architects, domain, cloud, solution... all came years later. So to be writing again about software architecture, which was also my first architect title, and I still consider my specialization area, is a wonderful thing. We know so much compared to when I started about architecture as a practice and as a profession that this is extremely fulfilling.

By the way here are 4 things we are looking for in the BTABoK. We are putting contributor names on articles again! Many many many architects have gotten benefit out of being aligned publicly with an article (as in they got jobs, promotions, speaking gigs, fame, infamy, whatever... not promising anything but still... :-)):

1. Contributors of patterns... real tested useful patterns and styles. One library to rule them all.
2. Examples... we need canvases, cards and code examples of all of the BTABoK concepts a) against the tinkleman case study. We could also use help with cleaning up examples that are sent to us by others.
3. Scenario articles... how to apply BTABoK concepts in tandem to accomplish a task. For example, roadmapping, business cases, value management and stakeholder tools is a great article on shaping the project investment policies of a company. Applying design techniques is another.
4. Competency articles... I am looking for new versions of competency articles. Find one of them and replace it...

Architects and Engineers are Different but Necessary

First, let's tackle the hard discussion. In the BTABoK, based off years of study of thousands of architects (4,500 skills assessments), hundreds of recorded hours of video interviews, thousands of speakers and presentations at our conferences, and thousands of hours of certifications, training development and authoring, there is no doubt, software architecture and software engineering/development are separate professions. They are both necessary. Their outcomes are higher quality when they are working together. They have competencies overlaps in some areas. The job market does not always recognize the difference. Your employer or current job may not reflect it. But the die is cast. We are separate partners needed for optimal outcomes.

Architecture for Business and Quality Attribute Outcomes, Engineer/Develop for Structure and Features

To make this holy (or unholy) marriage work, it is important to create a basis for shared decision making. That basis is inherent in the competency model. Software architects train in business technology strategy and human dynamics in addition to quality attributes, design and IT Environment. Engineers focus on technology depth, quality attributes (structure) and delivery. This creates a pairing that creates more valuable outcomes based on the evidence and quotes of our members, interviews, assessments and mentoring. Architects and engineering leadership need each other, and need to keep each other strong.

The Right Ratios Matter

An architect cannot be pro-active with more than 3-5 teams without changing their work (for example becoming review focused instead of design focused). Meaning a software architect will be optimally engaged with roughly this number of teams. However, software architects may scale their practice and maturity by leading larger and larger initiatives of architects/teams as long as they keep their own working relationship with a team or two. This ratio of 3-5 major stakeholders, teams, projects reoccurs a great deal when interviewing architects.

The ratio isn't just to teams, it is architects to the organization and business model. How many project/products there are in the organization is related to their size and complexity. This number of new change initiatives to architects is deeply telling. In places where that number is closer to 5% of IT, or 1 senior solution architect per medium project or larger. And where the largest projects have more than one type of architect, the surveys, interviews and success measures rise signficantly.

Without Execution Strategy Doesn't Matter

We say strategy and execution all the time but in fact only pay attention to strategy OR execution. Then we let 'the technical people handle it' or say 'thats a business problem' and we keep the two separate. There is the rub. The reason we fail at so many things is because strategy and execution are the same thing. If execution is done without strategic understanding, it is not going to deliver on the strategy, no matter how much you govern. Software architecture is the art and science of designing and delivering valuable technology strategy (architecture) through the rigorous and outcome driven delivery of complex software systems and solutions (software). But here is the thing, a technical lead (engineer) has never trained in business technology strategy... so yeah, there goes the strategy to execution part. Engineers are not architects. BUT we HAVE to have architects in execution. Or the strategy falls apart.

Using the BTABoK to do better Software Architecture

This is the first of the articles in the BTABoK welcome to software architecture series. It and the other articles will likely expand but the critical elements of architecture practice for software intensive systems is here. In fact, if you follow these guides you will find your understanding and capabilities in architecture far expanded. If you give back to the BTABoK (examples, articles, templates, patterns) as a contributor, you will find we can take ourselves to entirely new levels of understanding.

So how can we improve our practice with the BTABoK? Here are the overviews. We will be writing specific guides over the next few weeks to help you get up to speed:

• Role Clarity: The tools in the BTABoK team designers especially around stakeholder managment, agile team design, engagement model interaction points and job definitions provide signficant tools for designing the best interactions for the software architects and their environment.
• Career Path and Competencies: We have worked out exactly what skills you need to be a Software Architect... and how those differ from engineer. We are also awesome at moving someone forward in their actual level of readiness.
• Team Design and Assignment: Large architecture and engineering practices are all about team layout... The current btabok has a lot of tools for this.
• Decision Traceability: I would say we are close to having the best Body of Knowledge in the world for tracing decisions. From business model to serverless decision records... we can track a decsion from strategy to execution to measurement... and find cognitive biases along the way, it is rediculously powerful.
• Stakeholder Support and Communication: The btabok wins awards if there were awards for our people focus. The stakeholder tools in the btabok are exceptional and constitute a major practice method.
• Business Value Delivery: Do not be fooled by people talking about value. The BTABoK is the only architecture practice method that has an actual practical toolset for understanding and delivering value.
• Backlog Prioritization and Grooming: Work breakdown, prioritization, and assignment. The current BTABoK does an admirable job of this... Even better when you look at the content in our Core, Solution and Agile Architecture course... much more to do here.
• Lifecycle Planning: This is one of those areas we have nailed. I mean it. When you get good at applying the BTABoK this has become almost easy (kidding!). Still we have one of the most advanced practice models for architecture lifecycles on the market. It is yummy.
• Structural Completeness: My perfection desires are at war with my willingness to accept the awesomeness of what we have already figured out. Structural design in an architecture is never complete. And as per below, we have so much more to add to this section. But the method accounts for this and true complexity already and will be going a good deal further.
• Complexity Management: As I said, Im at war with my own desires here... long way to go, long way already achieved. We will dominate the architecture complexity discussion ere long. Mark my words.
• Quality Attribute Delivery: This is a never ending discussion. The BTABoK supports this and yet needs to do a lot better. For now the primary is in architecture design and analysis... more content to come.

Places where the BTABoK does not yet currently have enough information or enough support for the software architecture body of knowledge. Version 4 of BTABoK will be digging into these. The reason we are doing them after the above is because without the Core, the Value and the Differentiator for architecture the technical, the engineering and the depth become perverted or less valuable.

Try to understand, all of the following are easier with what is in the BTABoK now. But when I visualize what could be... well that is something else entirely. I envision a world where we actually research these topics with A/B evidence as to their efficacy. Where architects from different specializations but with enough shared knowledge debate their impact on the field. Where we explore real life outcomes of trying them.

• Engineering Views
• Data Structure and Depth
• Performance, Resiliency and other Quality Attribute Specifics
• Tier 1 Saftey Critical Systems
• Primary Viewpoint(s)
• Multi-'Language' Model Examples (C4, UML, SYSML, Archimate, etc)
• Multi-'Language' Examples (Code, Culture, Speaking, etc)
• Security
• Cloud, Services, UI, AI, Agile Delivery (ops and dev)
• Integration
• Patterns, Styles, Reference Designs
• Depth Requirements
• View Composition
• Lifecycle Navigation and Polymorphism
• Career Path Duplicity
• Purchasing Products
• Product Management
• Glossary

If you want to join the BTABoK as a contributor you simply need to start making contributions... You can find the backlog forming up here: https://github.com/Iasa-Global/btabok/issues

I am also extremely excited to talk about our partnership with No Fluff Just Stuff in the US. Jay Zimmerman and I spoke last night and we are doing suuch cool things in the world of software architecture... Can't wait to tell you more. Hint: you will find me in Denver at UberConf... https://uberconf.com

I wish you luck in your journey. Join us on ours, understanding lies in truth, truth lies in evidence, evidence lies in sharing.