Architects Are Not Here to Keep the Lights On

By Paul Preiss, Iasa Global

There are two roles in building a building… the innovator and the inspector. Which one do you want to be?

There is a persistent idea, and I hear it from executives, from managers, even from architects themselves, that architects are here to manage what exists. To rationalize the portfolio. To govern the estate. To make sure things, in some vague way, keep running smoothly. And I understand where that idea comes from. Organizations are complex. Someone has to understand the whole picture. And architects are often the only people who do.

But when we accept that framing, we slowly disappear into it.

The BTABoK is unambiguous on this. The entire practice model, every specialization, every competency, every engagement tool, is oriented around transformation. Innovation. Change. The delivery of new value through business technology strategy. And here is what I find genuinely remarkable after all my years of research into what architects actually do when they succeed… every architect type we recognize, business, software, information, infrastructure, solution, all of them, when studied carefully, are doing the same fundamental thing. They are change agents. Every single one.

This is not conjecture. We have implemented this in multiple international organizations with wild success. Real measured outcomes, real stakeholders, transformational change.

The Transformation Architect… also known as the business technology architecture body of knowledge. We built this because while linked in claims of big successes are common, there are real problems in current practices:

  1. Very few practices are united: each of the specialists report to different groups and have different priorities. And they don’t work well together.
  2. Very low focus on bottom line value creation: lots of cost savings, lots of reuse, very little change the business engagement.
  3. Low buy-in and value perception in stakeholder communities.

Instead, the BTABoK Methods Are Designed to Achieve the Following:

  1. Maximum value, velocity and outcomes in transformational and project work.
  2. Deep trusted advisor relationships with a strong change the business focus.
  3. Increased adaptibility and flexibility in business technology implementations.
  4. Lower exemptions and risk in architect-led engagements.
  5. Better outcomes with architect-led vendor engagements (on both sides).
btabok

The Business Architect Is the Tip of the Spear

The business architect in the BTABoK works with business stakeholders to identify where technology strategy produces the greatest digital advantage and then connects that to delivery. The whole point is that business architects retain strong technical skills, not to write code, but because they need to speak the same language as the specialists executing the change. They are the bridge between what the business is trying to become and what the technology practice is capable of delivering. That only works if there is an actual partnership with delivery on the other end of the bridge. A combination of Distinguished Business Architect and Distinguished Solution Architects is the dream most business stakeholders wish they could have. That is strategy to execution.

Software Architects Who Deliver

Software architects are probably the most delivery-connected of all the specializations, which is why it surprises me how often I see them in purely advisory roles. Reviewing someone else’s design. Approving someone else’s component choices. Attending stand ups without owning anything.

The BTABoK software architect makes the structural decisions that determine whether a system can carry the business capability it was built to support, and whether that investment compounds over time or decays. Those decisions belong in active delivery. The strong business competency the BTABoK requires of software architects is there so they can connect structural decisions to measurable value outcomes, not to make them more comfortable in governance meetings.

Information Architects and the Data Transformation

Information architecture is the most fragmented specialization we have. The title gets used for UX design, data management, integration architecture, and analytics, sometimes all in the same organization. The BTABoK treats these as focus areas under a unified specialization, but the transformation orientation runs through all of them.

Information architects are here to make data a genuine lever for business change. In a world where the most significant competitive advantages are being built on data, an information architecture practice that is primarily descriptive rather than enabling is pointing in exactly the wrong direction.

Infrastructure Architects and the Environment of the Future

Traditional infrastructure architecture was the most operationally focused role in the profession. Managing what runs. Ensuring continuity. Those things matter enormously. But the BTABoK reframes infrastructure architecture around the full compute and connectivity landscape, cloud environments, edge compute, IoT, distributed product ecosystems, the network substrate of the organization’s products and partner relationships. The future is going to be a device EVERYWHERE. Our compute will be everyone.

Designing the technology substrate that makes new business capabilities possible is architecture work. The distinction between that and keeping existing systems running matters enormously to how an architecture practice understands its own purpose.

Solution Architects at the Center of Delivery

Solution architects in the BTABoK are expert generalists who lead specialists through major programs, products, and projects. The BTABoK pairs solution architects with business architects at the value stream and program level so that strategic intent and delivery execution stay connected throughout the lifecycle of the work, not just at kickoff and not just at closeout.

A solution architect who is not actively engaged in a program, product, or project with real deliverables and measurable outcomes is not functioning in the role as the BTABoK defines it.

Program, Product, Project… All Three

One of the things I am most proud of in the BTABoK is that we take all three delivery contexts seriously.

Projects still make sense in many contexts. A defined goal, a funded scope, a beginning and an end. They are not obsolete just because agile became popular. But they are not the only context architects work in.

Products have lifetimes. The product lifecycle, from introduction through growth, maturity, and decline, is a natural home for architectural thinking because architects have always had to think about total cost of ownership, technical debt, quality attribute evolution over time. That is not a new idea borrowed from product management. That is what architects were already doing.

Programs are the coordination layer. Multiple products and projects working toward a shared strategic outcome. The solution architect at program level manages architectural coherence across a portfolio of delivery work. That is transformation at scale.

The Chief Architect Model

The BTABoK preference for seniority based titles, Chief Business Architect in a Domain and Distinguished Software Architect titles over traditional scope-based titles is directly connected to all of this. A Chief of Integration Architecture. A Chief Information Architect… Security Architecture. A Chief Software Architect of Consumer Banking.

These titles carry delivery responsibility. They are based in measured competencies. They are actually still building something we can name. They are not management positions.

When your senior architects look like managers they stop being architects. When their day work sounds like an jumble of hype words (architecting the future! indeed) then they have lost the very thing that made them architects in the first place… creating value for customers and stakeholders directly and proactively.

The analogy from medicine is one I come back to regularly. The chief of medicine sees patients! Up to 70 or 80 percent of the time, regardless of additional leadership responsibilities. The competencies that make a senior physician valuable are maintained through practice. Architectural competencies work the same way. An architect leader who has not been engaged in meaningful delivery for years is not maintaining the skills that make them an architect. That is a real and common drift and the BTABoK is specifically designed to resist it.

What the BTABoK Says This All Comes Down To

The architecture lifecycle runs from Innovation through Strategy, Planning, Transformation, Utilize and Measure, and back again. Notice what the measurement stage feeds. The next innovation cycle. The data from what is running today is the input for the next change. An architect engaged in the Utilize and Measure stage is not optimizing for its own sake. They are building the evidence base for the next transformation.

The societal contract for the profession, the reason architecture deserves standing alongside medicine, law, and accountancy, is that architects deliver best in class decisions on business technology strategy at appropriate velocity in complex ecosystems. Every word in that contract is about change. About delivery. About value created, not value preserved.

All five specializations. All three delivery contexts. All one profession. And it is a transformation profession.