Three Levels of Software Architecture
Photo by me, Will Thayer in Northern Minnesota

Three Levels of Software Architecture

Software architecture ensures that all stakeholders (users, owners, sponsors, developers) are well aware of the issues and strategy for a successful information system while emphasizing alignment of short/ long-term business goals.

Software Architecture

Software architecture serves a critical foundational role in successfully delivering information systems.? Ideally, software architecture presents the Why and What of a software project and iteratively throughout its lifecycle defines technically How it will accomplish its mission.? It includes diagrams such as UML or C4, other custom homegrown diagrams, and sequence diagrams;? it includes context with well-written problem statements, objectives, and key results.? Software architecture ensures that all stakeholders in a project are well aware of the business issues at stake and the strategy for the project while emphasizing alignment of immediate and long-term goals.? Software architecture evolves through time and some “How” strategies obviously won’t work as expected but at a minimum, software architecture answers questions of Why and What.? The How may drastically change throughout the development lifecycle (along with the who and when).

In my career, I have never worked on a software project without some level of software architecture.? This includes proof of concept (POC) projects.??

The goal of architecture is to establish a clear shared understanding of the issues and reasons for the project upfront while explaining current thinking of possible solutions for the future.? My first tech mentor, Don McCubbrey, encouraged me repeatedly to think about:

  • Where have we been?
  • Where are we today?
  • Where do we want to be in the future?
  • How do we get there?

These are critical questions that software architects answer.

Architecture means many things to many different individuals and the granularity of details is subjective.? Software architecture is not a science and whether the architecture is drawn on a napkin or encompasses numerous pages of boxes and arrows is subjective.? The point is to solidify shared understanding, buy-in, and expectations with appropriate levels of detail for different audiences.

Levels of Architecture

At a minimum, I profess there are three levels of software architecture granularity.? Modeling includes business domain-specific solutions such as back-office solutions with finance or customer-facing domains with storefronts.? These levels progress from conceptual to logical and to physical implementation.? The goal of software architecture is alignment and shared understanding of specifications/ expectations of an information system yet to be fully realized.? Stakeholders not only include development teams but also executives, sponsors, owners, users, testers, managers; and in most enterprise-level projects, the entire organization and beyond.

For most individuals outside direct responsibility for building the new system - a conceptual architecture is appropriate.? For the development teams, a fine granular physical architecture is necessary which increases team productivity.

Conceptual

A conceptual software architecture includes a brief concise upfront problem/ opportunity statement.? It explains ‘What Is’ and ‘What Should Be’.? It answers questions of;? why does this project exist, what business strategy is it aligned with, what are the future opportunities this project springboards, and what are the threats this project hedges against?? When we think of software architecture, we typically think of bloated diagrams with boxes and arrows that somewhat paradoxically don’t follow most reading styles and often are confusing to anyone not familiar with the domain that this architecture addresses.

A conceptual architecture should be a macro 30K-foot viewpoint of the concept.? This is an important artifact because it corroborates buy-in from all stakeholders.? This artifact, hands-down, is the go-to artifact for everyone to agree upon.? It is also handy for new entrants to the project, especially with large projects where newcomers frequently arrive or leave (especially VPs).

The conceptual architecture need not be complicated, nor fine-grained, and must ensure that this is our ‘North-Star’ destination as an enterprise (think KISS).? I have created such diagrams and artifacts called Domain Destination Architecture or DDA.? As practicing software architects, we all strive to make our diagrams self-evident.? Our diagrams should tell a story that leaves little misinterpretation.? It is vital for Conceptual diagrams of software to provide this understanding, just like famous napkin diagrams.

Here is the famous napkin diagram of the Guggenheim Museum in Bilbao, Spain designed by Canadian American architect Frank Gehry.

Here is Jack Dorsey thinking about architecture with Twitter on a sketchpad.

Conceptual software architecture is inspiring as a technologist because it opens complete creativity.? If done correctly, the audience immediately just “gets it”, just like the iPhone.

“Let whoever may have attained to so much as to have the power of drawing know that he holds a great treasure.” ~Michelangelo

Logical and Physical Software Architecture

This is where things get more complicated, opinionated, political, and real.? Let us talk about Logical first because as a hands-on developer, I believe the physical becomes clearer and easier with the concreteness of logical architecture design and requirements that are broadly accepted.

Logical Software Architecture

A logical architecture begins to separate the responsibilities and duties of a conceptual architecture.? The previous napkin examples have many details within them and to successfully realize the napkin concept, we group complexity logically with defined and grouped separations.? Domain-driven design is a good example of a logically separated software architecture methodology.

In Jack Dorsey’s napkin of Twitter, he notes ‘reading’ with user triples for identification.? Then, he denotes statuses like ‘going to park’ and even ‘video’ as an option for viewing ‘going to park’ for others.

There is logically separated domain functionality implied in this napkin, like ‘video’.? The video aspect of Twitter could include a completely dedicated team and ‘Domain’. The Guggenheim Museum napkin is more conceptually abstract.? It has no separation of functionality nor hint of the engineering reality of the building.? It is as if Elon Musk said, “I’m going to create a rocket at SpaceX and they are beautifully designed like this”.

When progressing to the logical from a conceptual architecture, ‘How’ business is done and the expertise of domain-specific context becomes increasingly vital.? This reminds me of a special talk by Simon Sinek titled “How great leaders inspire action”.

In Simon’s presentation on Ted, he talks about the ‘Golden Circle’.? Most, if not all employees, know ‘What’ their employers do.? However, little is known typically about ‘How’ they do it.? Even less is known about ‘Why’ they do what they do.? Therefore, in software architecture, it is extremely difficult to model the Logical architecture without the context of How from a non-tech business perspective.

In a recent engagement, we were designing and developing a new Auto-finance application.? During that project, which included 100s of people; there was not one accountant, financier, auto-dealer, or anyone who could answer the question “How does an auto-loan work from end-to-end today?” or “What happens and How does an auto-loan originate?”.? Let's say, hypothetically, we had to do this process completely on paper and manually.? What happens?? What are the steps?

If you cannot answer these obviously simple business process questions; then how do you expect to automate, innovate, and create this process via IT?

This is the conundrum of Logical Software Architecture.? You must have available subject matter expertise and collaboration with those designing an Information System for the future at all times.

Information systems are simpleton technology implementations with subject matter built-in.? IT, it does anything and everything you tell it to do but you have to tell it what to do.? Dreams of all-encompassing knowledge-based systems with AI are not a reality, yet.? Someone must tell the system the rules; and in this case, must tell it How an auto-loan works.

Physical

The physical software architecture is something that most enterprise stakeholders do not interface with or care to analyze.? The physical system is based upon a logical architecture that others supply to hardcore engineers who know how to implement physical systems.? I wonder though, how many physical software implementations and architectures would benefit from having a more profound voice in the logical architecture?? These professionals are usually kept in the basement with little other than toys to play with.? They are cool toys.? There is an incredible amount of talent and know-how in the basement.

In my experience, as a developer in the trenches, I have experienced conceptual and logical architectures and asked many poignant questions of Why, What, and ultimately disagreeing many times about How.? In my low-level experience, I get to physically implement the Why and What, with physical logical Hows that include many options.

So, How is this system going to be physically implemented?? As a technologist, you know, there are numerous ways of accomplishing any one goal.? There are countless options for how we may physically implement a logically defined How and more How options appear every week.? Physical Architecture is no doubt important and where the “rubber” meets the road so to speak.? Although, the Physical Architecture in this entire process is last.? At this point; the owners, stakeholders, and users are at their wit's end because of countless hours deciding upfront questions of use cases and requirements.? Now the engineers step in and start to build the solution.

Guess what happens?? There is no room for compromise, there is no avenue for change.? The people who implement the system are doing it one way with the details they’ve been provided, even if it is blatantly wrong.? As demonstrated by history, even if all enterprise IT systems fail at an astounding 30% of the time on average or worse.

Why is this Important?

Any information system is a team sport.? It is a collective and collaborative effort of many people.? The people involved range from first-time developers to executives sitting on boards of influence.? All of these people deserve an appropriate level of explanation for any information system investment that costs the company valuable resources.? I personally enjoy working on systems that have the maximum potential to disrupt business.? For this reason, I have been involved repeatedly in system development that quantitatively contributes to a company's bottom line.? This is one of the reasons why I work in technology because it has such a dramatic and potential impact for good.

Software architecture is a roadmap for success.? It is an imperative artifact for everyone to return to for clarity when things get mottled and confused.? Things will always become more complicated than they need be and the architecture helps set everyone back to a true path.? Think of the questions of where you are today and where you want to be tomorrow.

Final Thoughts

Software projects and development teams deserve good architecture that builds excitement, buy-in, and support while communicating clearly the value and return on investment for their efforts to build next-generation systems.? These systems are extremely important to businesses in order to compete.? Software architecture answers the question of where we are today and where we want to be tomorrow.? Imagine the extreme story of Blockbuster and Netflix.? I think Blockbuster completely failed whereas Netflix had an architecture for success.

Will Thayer is a business IT consultant with more than 25 years of experience in planning, strategy, development, and training. He has built numerous web portal applications. His expertise includes Big Data Analytics, management information systems, and system development life cycle practices. As an Adjunct Professor at the University of Denver, Will taught graduate and undergraduate students for 5 years. His research in Open EDI and XML EDI has appeared in books as well as trade periodicals in collaboration with Bill Joy and Michael Dertouzos.? Will is a retired Distinguished Engineer Enterprise Architect and his work on Domain Destination Architecture was approved and shared across a major Fintech enterprise.

Brian Jennison

Software Engineer

1 年

Great article, Will. In my experience not enough effort is spent on the the "conceptual" layer. Usually a developer team gets a vague description of what to build and they dive right in starting coding. An then rarely is the first iteration what the stakeholder really wanted. More back-and-forth during the conceptual stage saves a significant amount of time on the project and more often than not, reveals the stakeholder doesn't even really know what they want. haha!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了