Do You Need a Solution or Enterprise Architect?

By Gary Silberg, Senior Solution & Enterprise Architect

Although Solution Architects and Enterprise Architects are two different animals, they have a mutual respect for each other and typically work together. One starts things off and then the other takes over. The Enterprise Architect is the strategist and is responsible for all the planning, while the Solution Architect is more tactical in nature and delivers what has been planned. So, if you believe you need an architect, how do you decide which one to hire?

The best person to answer that question is someone who has been both. I’ve worn many architecture hats over the years. I’m quite used to changing hats. When I’m not doing architecture work, I like to perform in musical theatre. I often change costumes between scenes and sometimes play more than one role in a show. It’s no wonder that I’ve worn both hats as a Solution and Enterprise Architect – even at the same time.

How are Solution and Enterprise Architects the same?

The following are some key capabilities that both the Solution and Enterprise Architects should demonstrate in their respective roles:

Focus on the business value of technology-enabled initiatives

Architects are very good at validating whether a new process or solution can generate measurable business benefits. They are also good at aligning solutions with overall business strategy and objectives.

Without this type of architectural perspective, you can end up “paving the cow paths”. This is the expression I use for automating existing business processes exactly as they are currently performed. In other words, you shouldn’t simply write code to make a new solution do exactly what is done now. If you do, you’ll end up with a jumble of winding paths instead of a clearly laid out solution.

Excel at structured problem solving

Every initiative will encounter issues or problems that require solutions. This can happen up at the enterprise strategy level or down at the individual software component level. Architects are good at resolving these problems using a disciplined approach. Each item gets documented, including the requirements addressed, the stakeholders involved, and the alternatives identified. The options are then evaluated against chosen decision criteria, leading to a recommended alternative. The final outcome is recorded, including an explanation if the recommendation was not selected.

I find that these recorded “design decisions” are extremely valuable to demonstrate attention to detail and to avoid rework. Design decisions enable the team to base decisions on facts instead of opinions and emotions. As part of organizational change management, design decisions also come in very handy later to answer questions from business users about why the solution got built in a certain way.

Use models and diagrams effectively

One of the primary techniques used by both architects is the use of diagrams to illustrate and simplify complex problems. Unfortunately, some architects overcomplicate things by using arcane modelling rules with too many different shapes and colours to represent different concepts in one drawing.

My approach is to create “Sesame Street” diagrams. To simplify things for my audience, I try to use the fewest possible constructs in my models. In this way, anyone from programmers to executives can understand the diagram without having to remember exactly what a blue square or a green circle is supposed to represent. Simplicity and consistency are the driving principles.

Employ non-authoritative leadership to influence others

Generally speaking, the role of the Project Manager is to “tell” others what to do. PMs define project goals, establish the budget, onboard and offboard resources, and assign work to the team. They also communicate the schedule, determine when tasks are completed, and report on progress.

The role of the architect is more often required to “sell” ideas to others. Architects make sure that all participants in a project share the same understanding of key decisions and concepts, while they convince others to buy into these ideas. I’ve learned to tailor my messages to the various stakeholder audiences in order to promote joint ownership and to ensure that there is clarity and collective agreement on key project topics.

Stay up-to-date on transformational business and technology trends

Architects can act as a bridge between the business areas and the latest technology trends. By understanding the intersection between technology solutions and their ability to support change in an organization, they can champion new initiatives to enhance and grow a business. In this way, innovative new solutions can contribute to increase productivity and decrease waste.

These include the so-called “SMAC” areas of Social Media, Mobile, Analytics (Big Data), and Cloud, although these have already been around for a while. Architects also pay attention to current forces driving enterprise digital transformation, including the Internet of Things (IoT), Artificial Intelligence and Machine Learning, Blockchain, Robotic Process Automation, Virtual and Augmented Reality, and Quantum Computing.

How do Solution and Enterprise Architects differ?

A Solution Architect is more like a surgeon who operates on someone to fix a problem, and the patient returns to normal life in a short time. An Enterprise Architect is more like an internal medicine specialist who treats a patient with a chronic illness over a number of years to improve the person’s quality of life. Here is a comparison table based on some key aspects of both roles:

However, I want to point out a couple of things that should NOT be part of the responsibilities of the Solution nor the Enterprise Architect:

DON’T act as the standards police

Architects are most successful when they help projects to succeed. Commonality of process and technology can be beneficial for an organization. But once architects are merely policing projects and rejecting aspects based on strict criteria, they lose the ability to positively influence the initiatives. Solution alignment is best achieved through working collaboratively with projects early to convince them of the advantages of various design choices.

DON’T focus on lists of standards

The first deliverable many architecture teams produce is what I call the “red/yellow/green list”. You’ve all seen these. Each technology classification is listed down the page – for example: server type, operating system, network software, database technology, and programming language. Three “colour” columns follow across the page. “Red” items are forbidden to be used by new projects. Although some legacy applications may still use them, they need to be phased out. “Yellow” items can be used under certain circumstances, but must be pre-approved by some kind of review committee. “Green” items are the preferred choices for new projects and don’t require any approvals.

The reasons why products are placed in certain columns vary. They may be due to cost considerations or reducing the number of skills needed by the support teams. Or they may be due to personal biases or the persistence of the technology salespeople. Whatever the reasons, these lists become out-of-date very quickly and again lead to architects being asked to enforce rules on project teams. In the end, each project should be allowed to choose the optimal solution for the enterprise as long as the full development and support costs are carefully examined.

So, which do YOU need – a Solution or Enterprise Architect?

If you have a project which needs . . .

•     a champion to make sure you get a quality result that meets the business requirements and delivers the promised benefits

•     a leader who can help manage risk by motivating technical staff and carefully documenting key design decisions

•     a “been-there-done-that” expert who can estimate work effort and navigate the intricacies of application integration and data  conversion

. . . then hire a Solution Architect.

If your company needs . . .

•     a visionary to bring ideas for enterprise digital transformation to your executives

•     an advocate for a multi-year business and technology roadmap to increase enterprise performance and create new value for your business

•     a strategic thinker who understands your business inside-and-out and who can see how to align a portfolio of projects with your business objectives and plans

. . . then hire an Enterprise Architect.

Whichever one you do hire, you should get a valuable team member who contributes to your success.

As a final thought, in a recent show I did, ironically called “How to Succeed in Business Without Really Trying”, I played two roles. In the first act, I played Mr. Twimble – the Head of the Mailroom. In the second act, I played Wally Womper – the Chairman of the Board.

Mr. Twimble was more like a Solution Architect. He was interested in the shorter term goal of effectively getting the mail delivered every day. Old Wally was more like an Enterprise Architect. He looked at the long term goals for the organization to be successful. I guess it’s true that “Art imitates Life” – and some people (like me) can act in both roles.