The true value of a software Architect in an organization is the ability to translate the business’ vision and strategy into effective enterprise change, usually starting with the solution architecture. This means that an Architect needs to truly understand the business drivers and how they lead to features at the product level in order to successfully guide a product’s architecture road-map. Inversely, an Architect should be able to communicate both the technical and business aspects of this strategy to any audience, technical or otherwise.
The communication style used to deliver the message to distinct groups varies widely based on the audience’s duties. Technical folks focus on the technological implications of the architecture strategy and are usually more interested in the how rather than the why. If you take a group of developers they would rather know how their specific areas of concern are affected and what they need to focus on.
Switching gears to business folks such as VP’s, PM’s, AM’s, etc… the conversation switches from the how to the when, why, how much, etc… The key message these groups are interested in is how the clients and velocity of feature delivery will be affected. While bits and bytes might be interesting, business folk have other value drivers they focus on, such as how much revenue are they generating!! Yes, this might be silly to most techies (why else would the open source community not only be so prolific but ever expanding), but at the end of the day it’s what pays your paycheck!
The real challenge is effectively communicating value to both of these groups using a unified, consistent message. Techies will place value on code while business folk place value on revenue generating, customer appeasing, market share raising, competitive advantage driving features! While these aspects are inextricably intertwined it is, without a doubt, difficult to deliver a global message that can cover both groups at the same time.
Creative flexibility is something every professional is empowered with, and with this in mind, I decided to experiment; to come up with a different mechanism by which this consistent message can be delivered. But before I proceed I should take a little more time to familiarize you with the context of the problem space and environment.
As an Enterprise Architect responsible for several products that span over 20 years worth of development and bring in close to 100 million a year, I am charged with not only keeping the architecture modern, but agile and flexible enough to quickly adapt to the business’ needs. This allows our company to quickly react to the business environment and ensure maximum market penetration.
In order to accomplish this, a flexible underlying architecture is mandatory. This means proper architecture layering using the tried and true business, data access, presentation, and so on layers.
Communicating this need to developers is relatively easy. Through several working sessions one can show how 100 lines of code can turn into 2 lines of code through the leveraging of a proven, standard framework which facilitates the various routine actions every enterprise system needs.
Communicating this to the business leaders, messaging why they should spend several man years’ worth of effort to align to the architectural vision, proves a little more challenging. Since this type of architectural effort is usually approached most successfully through incremental change and has long term tangible benefits, one can support and back such initiatives through peers, experts in the industry, white papers, amortization of effort, and so on.
Taking into account the two different forms of value messaging mentioned above, it is easy to find it difficult to envision how a unified communication mechanism can be employed to achieve the same result, the focus of each party is distinctly unique.
After a few high level discussions with individuals from both the technical and business groups, it was clear there was general skepticism rising across both groups in regards to the architectural road-map and its value. In an effort to demystify and attack as many of the concerns as possible at the same time, I decided to try something new, to try to deliver unified, consistent, value focused message that can apply to both groups.
In order to address as many concerns as possible, I gathered all of the key stakeholders across all of the business units; both technical and business oriented, and decided to play conductor rather than professor.
If you put business folk and techies in the same room, this is usually what you end up with:
This happens when either side leads the message. Taking an abstract viewpoint that lightly touches each group is difficult, so why not conduct the message through vocalization by members of each group? Let the questions drive the conversation and let the answers drive the messaging of business value!
I started the meeting by clearly communicating the goals and objectives: to demystify and clarify the intention of the architecture, and to address the high level, highly visible, high risk concerns that exists. Hidden, or rather not blatantly visible at first, in the agenda is how the solution not only addresses all of the concerns, but delivers value by, in most cases, completely eliminating the concerns from existing in the future.
After a quick recap of the new architecture and how it will be implemented, I started taking questions and concerns from various team members.
First example raised by a business leader:
Each time we upgrade our SQL server, we have costs tied into the development and testing time needed to modify the dynamic SQL queries in the code to meet the new semantics. This can be very expensive, slow down our ability to react to upgrade requirements, and having extra layers in the solution can only slow us down.
Answer: The new architecture abstracts the syntax specifics by leveraging the Entity Framework and NHibernate, ORM frameworks, thus eliminating not only the concern of how we are dealing with the problem, but eliminating this problem completely by removing any future rework when upgrading our SQL servers. Additionally, through the use of unit testing around the data access layer, we can guarantee the quality of our data access components, something that is not currently possible.
Suddenly, by addressing one issue, multiple key value points are communicated.
Second example raised by a support engineer:
We are utilizing custom SQL stored procedures to expose custom functionality to our customers. How will the new architecture allows us to do this?
Answer: The new architecture allows custom business logic through a plug-in framework. This allows your custom functionality to leverage the data access components, logging, metrics, security, etc… that are already exposed. This means custom functionality can be implemented quicker, has higher quality, and can be unit tested in isolation. Additionally, because your solution occurs in code versus in SQL, it scales better and the chance of causing database contention is minimized.
One by one the top concerns were addressed and a high level message of quality, hyper productivity in an agile environment, and an overall modern approach was painted. This messaging involved the audience’s direct involvement, which drove higher attention and understanding, and ultimately converted skeptics into evangelists (more on scaling yourself in an organization later).
While this approach is by no means novel, and I’m quite sure many books have been written on the topic, I hope that sharing my experiences helps some readers give this approach a try. Having tried different communication styles, and all of them having their own strengths and weaknesses, I decided to experiment with this style and ended up adding an extra tool to my toolkit.
There is no such thing as too many solutions to a problem.