Solution Architecture

Michael Rockwell -- Solution Architecture

The name solution architecture is sure invocative of the big picture. When you think of a
solution, it includes the hardware, software, and supporting people and documentation to solve a
problem. Solution architecture starts with an understanding of the problem–a really deep
understanding–and this is where so many projects fail. Too many people have the idea that
solving a problem is all about coding. The coding is the easy part compared to the contemplative
effort required to gather requirements, envision the solution, evaluate the options available for
the solution, do the time/people/resources tradeoffs, design the solution, and then communicate
all of this to the developers.


Having been in applications development for 25 years, and doing solutions architecture for over
15 years now, I have gained some insights into what it takes to create a successful solutions
architecture. Here are some of the things that I have found to be true, and this section contains
insights from a number of other architects as to what they have found to be true.

Insights

Get the vision right
I cannot stress this enough: keep working to clarify your understanding of the desired solution.
If you come from a development background, your disposition is to start working on a solution
from the moment the problem is stated. The effect this has is that the rest of the conversation
sometimes gets tuned out while your mind turns to solving the problem that you have heard. It is
important to resist this urge and pay attention so you can understand what the person is saying.
Ask questions and challenge the things that you do not understand. Come at the problem from
many different angles; make sure that the solution vision is clear. I have had the opportunity to
work on projects with teams from all over the world, and the approach to solutions architecture
has been quite different.

Next, I am going to give some examples from my own experiences. Please do not take these
examples as being a generalization of a particular people or culture, but simply as illustrative
examples. My examples are based on my work with teams in India and Eastern Europe. The
experience of working in each of these locations was radically different. In India, the general
answer was always immediately “Yes, it can be done”, and then the developers would go off to
huddle and try to figure out what they thought was being asked for in the solution. In Eastern
Europe, every request was responded to with a barrage of questions and unclear ideas were
challenged until everyone had a clear understanding of the desired solution. As a result, from
these projects I was often disappointed in the easily accepted solution from India. While, on the
other hand, I was delighted at how the solution from Eastern Europe met and exceeded my
expectations. I should add that the Eastern Europeans really made me work hard to clarify every detail, and it was not a comfortable process to work through the details. Interestingly, I was also uncomfortable in India but for a very different reason, I was never sure that the developers ever understood me, as my ideas were accepted very quickly and taken as suggestions rather than requirements. My fears were realized when the delivered solution did not meet the customer’s expectations. I cannot over-emphasize the need to not move off of envisioning until the requirements are crystal clear.

I know that at this point some readers are thinking in terms of agile development. Having a clear
vision is not counter to an agile approach, and in fact it is even more necessary than with other
more formal methodologies. Agile is very much reliant upon people as opposed to process in
order to deliver the desired solution. As such it is essential that all the people on the process
have the same understanding about what they are developing. This brings to mind a story I heard about the early days of the space program – one day, a dignitary was touring the space center when he noticed a janitor cleaning up and asked him what he was doing. The janitor replied that he was putting a man on the moon – a great example of a communicated vision. In this case, everyone knew from, the president to the janitor sweeping the floor, that the vision was to put a man on the moon. Everyone then did their part to make that vision a reality.


Communicate, communicate, and communicate

Architects must have excellent communications skills. Communications skills are the skills that
I work on the most because they are the most critical for an architect. Don’t get me wrong:
technical skills are an absolute necessity, but without top communications skills, it’s going to be
difficult to get your vision into the heads of others. Many of the disciplines, attitudes, and ideas
that I discuss in my IT operations article also apply to solutions architecture. The highest
responsibility of an architect is communicating the solution to the business leaders, technical
leaders, and any other interested parties in a language that they understand. Architects need to
have a mastery of three languages: business language for communicating with the business
people, industry language for communicating in the vernacular of the business, and technical
language for communicating to the technical leadership and the developers. I personally have a
dual degree having majored in business (marketing) and minored in engineering. I actually
started out in engineering and then started taking business classes in my junior year. At a job fair job fair I kept hearing that I should take some business classes because I would be out working with business people and would need to understand their world. Thinking back, my team won an engineering competition not because of the technical merit of the solution, but because we had given the business case for the solution to a panel of judges who happened to be all business people. We spoke in a language that they could understand.

We need to speak in a language that an audience can understand. It is often the case that the
audience will not tell you when they do not understand you, and a confused mind will always say
no. So be sure to understand your audience, and then be sure to speak their language.
I have worked in many different industry sectors, all with their own specific domain languages.
As a result I picked up a habit early on in my career that has allowed me to quickly learn each
domain. In most business lobbies, trade magazines for that industry are displayed. I would read
these magazines as I would wait to meet with the client. I would also take the free subscription
cards for the journals and send them in to get my own copies of the periodicals. Granted this was
before the Internet, which has made industry specific research much easier. The point is that you need to become familiar with the domain in which you will be developing a solution. And while
industries and domains. This allows you to be like a bumble bee and cross-pollinate the best
ideas across industries. I have also found that the DNA of most architects has a hunger for
knowledge in a broad range of subject areas. Architects are interested in knowing about things
and understanding how things work. Architects can then synthesize this knowledge into creating
solutions.

It is assumed that architects know the technical language. Yet this is not always the case as not
all architects come from the technical ranks. And even if an architect comes from the technical
ranks, their vocabulary and experience may still be narrow enough to hinder communications to
all parties. I believe that an architect needs to understand several development methodologies
and development environments, and also understand infrastructure, security, databases, business
integration, and operations and support. Blindness in any of these areas can cause problems,
however such limitations can be overcome with a team of architects and or a good network of
peers. Microsoft’s own Certified Architect certification requires that a candidate interview with
a panel of experts and answer questions and compare and contrast many non-Microsoft
methodologies and technologies. Someone with an exclusive but deep expertise in only
Microsoft technologies will likely fail the interview.

Leave no man behind

I had a project over a decade ago where I architected a solution for a new college registration and
student management system. I went to work and architected a state-of-the-art solution which
was more innovative than any other system in use at the time. But the customer kept coming
back and telling me that they didn’t understand something. Eventually, I was taken off the
project and given a bad review. Their feedback to me was that I just did not get it. Several
months later I ran into the manager of the project and he came up and apologized for the bad
review. He said “At the time I thought that you were far behind the rest of us, but after rereading
your architecture and recommendations, I finally know that you were so far ahead of us that we
could not see you.” This made me realize that I needed to go back to where the customer is in
their IT journey of understanding and to patiently bring them up to my level of thinking. As
architects our minds can be far into the future, as they should be, but we also should not assume
that the rest of the team can see that far. We need to communicate, educate, and mentor the team
to our level of understanding so that they can understand the full vision. Be like a US Marine,
leave no man behind.

Experience

Great architects come with many years of experience. But often I see developers expecting to
become architects overnight. My advice to all aspiring architects is to become a consultant and
spend several years working on a diverse set of projects in a number of different industries.
Read periodicals and books in a wide range of business, industry, and technical areas for two
hours each day. IT architecture is a continually evolving field which requires a habit of life-long
learning to be successful.