The Architect - Guiding Principles
My career has been centered on both the evolution and simplification of enterprise architectures for large enterprises. I believe in developing enterprise architecture principles as a foundation for the definition of solutions that meet the strategic needs of an organization. These principles don’t reference technology—instead, they drive technology decisions.
If used correctly, these principles allow companies to avoid building the right solution the wrong way, or worse, building the wrong solution the right way.
The focus of this article is not the Design Principles of the Architecture but the Principles that guide Enterprise Architects.
These are principles that I shared with the Enterprise Architecture teams I led:
1) Drive Innovation
Innovation shouldn’t start with a conversation about technology—It should start with a conversation about capabilities, process, and people.
There are few enterprises using the full set of features of the technologies they’re investing in. Most times, the acquisition of new technologies comes with hiring of corporate executives who have been able to drive change in other companies leveraging a certain technology and they replay their recipe in a new organization.
Efficiency stems in process optimization first, people next, and then technology, yet too often the process works the other way around. We buy technology, train people, and design processes to make the most efficient use of the technology. Even worse, we adapt the technology to fit with an older and non-optimized process.
2) Create High Value for the Enterprise
Defining value can be complicated. More enterprises need to spend time defining what value means to their customers and how every project in their portfolio is contributing to creating that value.
A good exercise here is to separate projects that should continue to receive investments versus ones that will only provide marginal or isolated value that won’t contribute to the bottom line.
3) Be a Trusted Advisor
To be a trusted advisor, an Architect must intimately understand their industry—not just technology. A conversation with the business customers shouldn’t only be about the technology, but about how the solution you’re about to design will set them apart from their competition. A conversation about business outcomes will always win your customer’s attention.
4) Promote Collaborative Decision-Making
Designing solutions is an iterative process where details mature over time due to increased mutual understanding of the business/IT contribution to solving the problem. My favorite approach is to offer multiple solutions and explain each in plain English along with pros and cons, and short and long-term implications of each choice. While we all understand time pressure and have all been in a classic situation where there were “too many cooks in the kitchen”, inclusion is key.
5) Make Data Driven, Fact-based Decisions
W. Edwards Deming once said, “Without data, you’re just another person with an opinion.” To promote change, it’s important for Architects to effectively describe the value of the proposed solution. This happens when “HiPPOs” (Highest Paid Person’s Opinion) run your company, so in order to create buy-in for change, you need to be armed with facts to prove that the HiPPO might not the best decision for the company.
6) Promote a “one team” Culture across IT and the Enterprise
This is the failure of most organizations, especially ones with a federated operating model for enterprise architecture. A federated model for architecture makes it difficult to drive the enterprise agenda since every business unit behaves as its own separate enterprise. In a climate where both business and IT leaders are running their own agenda and not the enterprise agenda, it’s important an enterprise Architect remains true to the focus of the enterprise. A team is successful when the sum of the capability of the individual parts is exceeded by the collective capability of the entire team.
7) If you can’t Build it Simply, you don’t Understand it
To build it simply, the Architect must have a firm understanding of the solution impact to the current business architecture and especially value streams, processes, and business capabilities.
I know, we hear the word, “simplify” a lot—IT solutions are often developed in the vacuum of a single project with little consideration given to the impact of the enterprise. This results in hundreds and sometimes thousands of applications and technologies needing to be maintained and supported.
8) Recognize Courage and Success
Good Architects know how to build personal networks and the best way to do this is to freely give recognition of success when it’s due. Since Architects are typically introverted, recognizing people with a simple “thank you” in an e-mail goes a long way in building trust, and will help you when you need to get support in the future.
9) Think Big, Start Small, and Scale Fast
The era of “build it and they will come” is over—Rome wasn’t built in a day, and you won’t build or transform an enterprise in a day.
Visualize your goal and learn to communicate it persuasively. Organizations look for successful execution and results, and often a small example of success can be a better explanation of your plan than the plan on its own without any tangible results.
Efficiency is the key to high performance. It’s true some companies can afford to buy their way to the right solutions, but in my experience, I can tell you that the resulting enterprise architecture is bloated and inefficient.
I always start with asking myself the question: If we were to start this company today, what would the architecture look like? The answer is usually a very modern and efficient architecture.