Chasing the Tech in Architect

The last year I have been working to deeply refresh my understanding of implementation trends again. Microservices, React, Native, Serverless, Containers, DevOps pipelines and Integration variations… messaging, Kafka, cloud security patterns, etc. It has been a fun little journey and one that will pay off for the management and maintenance of the current BTABoK. For while I am completely satisfied that the basis for the business focused portions of the BTABoK are good, I have been interested in exploring the engineering side of our profession. This often contested place is one where opinions (like their smelly brethren abound) and yet fact is often hard to find. I will start with what Im building (and feel free to join me building it!) and some of what I have found.

The Business Case for the Tool

The basis for the tool and API I am building is a tool to manage the BTABoK itself, but also to manage any body of knowledge and any form of assessment against it. This will allow architects to have a free (or mostly free) tool to understand and interact with established techniques and best practices. It also allows us an easy to use way of versioning, sharing, enhancing and adopting working methods and techniques. The goal is to have a broad-based system of experienced committers who use, review, update and approve of working techniques in the world of architecture.

The Context View of the Tool

The tool is both functional and a set of design exploration elements itself. I am attempting to mimic a modern recommendation for solution structure, though I am documenting decisions that make this seem unnecessarily complex.

For example, I am splitting domain-based deployment units in the following ways to understand quality attribute, velocity and development value a) original microservice, b) grouped ‘macroservice’ in single deployment unit, c) domain driven service, d) cellular compute/hexoganal service patterns. I have found that the domain and ‘macroservice’ design decisions are by far the easiest to maintain as a single delivery expert, but also that an api orchestration engine is really very very similar to previous facade style single deployment unit service thinking, just with a ridiculous level of contain complexity added on top. What I have yet to discover is that specific point of effectiveness.

The core technologies for the tool are React with Refine.dev , Auth0, Spring Boot, Java, Postgres. I am doing some aspects of the system with RabbitMQ and Kafka to demonstrate integration patterns. I will publish the Context View and decision records as a part of this series of articles.

A Big Surprise

I have been overwhelmingly surprised at how similar development problems and techniques have remained in the last twenty years and how unattractive and low-level the patterns remain. Using Refine.dev and Spring Boot 3 and Auth0 gave me a semi-attractive UI in a couple of days but nothing I wasn’t able to do in Ruby on Rails, Struts and similar UI/Services/Data abstractions over the years. In fact a good portion of it is quite a bit more complicated and ‘ugly’. Reacts data handling methods are both verbose and quite complicated, forcing the UI side designs to be overly asynchronous (again I am not expecting 10 million concurrent users!). More on this as I add further user stories and epics… I am hoping the added architectural complexity shows its value and design elegance as the application scales in domain complexity and business logic. I have been quite pleased with the structural flexibility and options I have for each of my decision levels. But jeez, do we really need thirty open source projects for every type of interaction... Spring Boot just launched a Modulith (modular monolith) which maps to domain driven design concepts. I have decided to call these Macroservices or domain services because the word modulith is just stupid.

To-Cloud or Not

I love deployment to my local environment and absolutely hate moving to production so far. I wish I had a data center option of my own. Ok it is defintely less work than requisitioning a server... but ugh it is not an elegant experience and makes the dev and integration environments feel cludgy. CLIs and command prompt jockeys have never impressed me. Ok we get to feel like Neo in the matrix woohoo… The deployment methods today are almost more arcane as our AS400 days and a good deal more error prone. Im using Digital Ocean but will be adding serverless and containers in AWS, Google and Azure just for fun.

I am working within continuous integration boundaries with a nod towards continuous deployment. Obviously with just a couple of us (let me know if you want to co-author) it isn't that complicated. Jenkins remains effectively the same as always. Secrets are a pain as well as other configuration information. One new area for me has been continous database deployments... I have a feeling I will trip my feet on that quite a bit but it does offer some exciting possibilities.

Architecture and Engineering

While much of our focus for the BTABoK originally was making a suite of techniques for architecture teams at the practice and strategy level, it is also extremely important that we provide reusable tools at the execution level and that these tools be taken into account and traceable to the more outcome, strategy and stakeholder side of the BTABoK. Only then will the knowledge properly connect all practitioners of architecture into a unified and effective practice.

The BTABoK describes architecture, engineering/delivery as separate professions and trades. Architecture and engineering have overolapping responsibilities and competencies in certain areas but they remain separate. This policy best supports the individual value of both and evidence (surveys and interviews) suggest that while other configurations are possible, a program work is more successful if both professions are present. Meaning a lead engineer and a lead architect create better outcomes than when their is only one. However much of this is context sensitive and much more research is necessary in the space before we get conclusive recommendations.

It is the belief of most of architects I have interviewed that of all types should have technology depth in their competency model at some point in their career. While business architects may have had that in very early stages, it keeps all of us grounded in the business technology strategy of the organisation.

Areas of Exploration

There are a lot of people exploring these avenues, however from what I have seen most are doing this in a hyper-focused way which either distorts the results or creates bias in approach. For example, both AWS and Azure maintain pattern libraries. Many of our corporate members do as well. You will find multiple software architecture practices and yet they miss the bigger picture of architecture treating it as synonous with software engineering. And each of these libraries uses similar names but are subtly or grossly different. That is both a massive waste and a fatally flawed quality approach. That is just one example. The BA Guild focuses on the BizBok, but it excludes roughly 80-90% of the employed architects on the market, creating a sort of bubble mentality. There is nothing wrong exactly with this approach if it was inclusive of other types of architects but by making these proprietary and exclusive it builds a separated island in our professional practices. Rifts and knowledge gaps that cost millions if not more of wasted effort and poor communication. Think about how disconnected your business and solution architecture practices are in competencies and outputs. That should

The following areas are what we are exploring for full support in BTABoK 4 which I hope to deploy next year. These are not the only areas as we continue our exploration of value, roles, capabilities, career, competencies, business strategy and operations tools.

Solution and Technical BTABoK Development

The goal of these sections is to display some early thinking in chasing useful and effective tools for the BTABoK in heavy technology environments. These environments are dominated by structural reasoning, technical depth, team decisioning, features or functions, testing, quick iterations, exploration and experimentation and deep interdependencies. Thus the higher scoped business-based decisions, solution roadmaps and stakeholder tools often don’t ‘map’ perfectly to the daily lives and interactions of these architects. At the same time it is important that the tools provided map easily to those more business outcome driven areas of architect skills.

In all cases we are giving credit to current thinkers in the spaces while looking for ways to adopt there thinking into the open source toolset, again without attempting to acquire private IP. If you want to contribute to any of these areas please do so by joining us on the BTABoK team!

Product/Solution

The current lean business case method in the BTABoK is excellent from an investment planning and project-based thinking pattern. So it works well in companies that want to change or create new ‘products’. However, it would also be beneficial to be able to take a more product-based starting point focused more on feature, market need and product area. This should also include lean change thinking to better map to deployed solution spaces and existing technology landscapes.

The product canvas and lean change canvases are a great starting point for this and should be added as excellent starting points in product leaning, technology-driven or solution-led scenarios.

Example Product Canvas… coming soon.

Example Lean Change Canvas… comming soon.

By creating these canvas methods and updating the corresponding BTABoK articles we allow more traditional technology, solution or product focused architects to have a more comfortable starting point in the structured canvas approach. However, if the appropriate value, roadmap and strategy concepts are not understood they will lack the depth and robustness of outcomes of the more strategic business case driven thinking.

Quality Attribute Library

The following example canvases are starting points for a set of quality attribute articles needed to begin deeply understanding our shared quality attribute knowledge and design techniques. There is much said about availability, performance, security and the like but it is necessary to study methods for managing these both in-depth in a solution design space but also as a group. Our upcoming security architecture training, certification and technique library led by Wayne Andersen, is an example of the possible exploration in this rich field. Additional work for the other measurable quality attributes is needed by the field.

Domain/Event Storming with Capabilities

In a recent conversation with Nick Tune who is a leader in this area it has come to my attention that the DDD group of technologists and the business capability leaders in our business architect specialization and the integration architects in our service mapping layers are all jumping around the same tree. And yet, the terminology, techniques and communication of these groups seems to bee deeply entrenched and highly askew… Domains in DDD are remarkably similar to business capability models and both drive technology service implementation and product usage in a company. Take a look at the DDD canvases we are adopting and connecting to the BTABoK alongside the existing capability cards. Notice how their scopes and relationships overlap in really elegant and beautiful ways. If we could get these methods working together it will create an immediate bridge between our business, software and information architects. I am looking to people like Brice Omniski who authored our integration architecture course to begin helping us to bridge these thinking paradigms.

Deployment and Team Structures

Containers, serverless, service composition and deployment units often relate directly to the teams used to manage, delivery and own them. And yet, these team structures were only partially represented in the BTABoK. Nor were there solid worksheets for understanding teams and deployment units. We will discuss the Development to Operations side of this and tools there in a moment but we are exploring the use of the following facilitation tools and whether they can be made to better support our work in these areas.

Part 2 Exploration

The following ideas and concepts are being evaluated as well for inclusion in version 4.

Technical Service Design - This one is quite desirable. All over the world people are talking about products, services and technical capabilities and how they map to business capabilities. In addition there is DDD and how that maps to inner services. This is a place ripe for simplification and workshoping. Expect to see this happen!

View Consolidation and Separation - We would like to get a long list of views in the marketplace and links to them. Viewpoint Libraries are the backbone of some frameworks. For example C4 is a viewpoint library by Simon Brown. However, it does not effectively cover business views, infrastructure and operations views. More to come but if youre interested in the methods for describing and modeling architectures this is a fascinating topic area.

Technical Capability/Service Mapping - As before we need a series of techniques cataloged for describing the relationship between capabilities and services. There is good work in solution spaces for describing relationships between loosely coupled services but it does not have wide-spread adoption.

Technical Loans - The BTABoK has identified that Technical Debt is a broken metaphor alone as much debt is created on purpose. We call these technical loans and you can see the technical loan card here: Technical Loan Request Card | IASA - BTABoK It would be better if we were to gather up relationships between this and legacy modernization techniques as the advice in industry is all over the board.

Universal Principles and Pattern Library - Architecture styles, reference models, patterns, principles, guardrails, standards... these terms are both heavily used and almost immediately abused. We need a basic method to our madness. The BTABoK has predefined most of these basic ideas. But now we need the catalog. The patterns resident in the vendor catalogs disagree with each other and are woefully incomplete. Also it seems that most principles I see are basically copies of each other except extremely poorly done. We need a real, living pattern repository and not ChatGPT (wait until I tell you those stories).

These are just. few of the areas of architecture and engineering we are evaluating for BTABoK 4! Hope to hear from you on more. As always to become a commiter you have to commit!