Keys to the Kingdom
Summary: There are four keys to an architecture that unlocks business value; to know them is good, to use them is great. (3 printed pages)
Ever since Y2K, business has become more sensitive to the impact of technology and has sought to improve the alignment of business strategy with technology. Right after the Y2K scare, I was charged with leading business innovation by using technological means. I was, however, stuck in the Matrix of "the latest and greatest" and led my team in the creation of technology innovation, but little in the way of business innovation—that is, until a wise colleague (Kyleel) introduced me to the "keys to the kingdom" (the blue pill). My eyes were opened and, through diligence, I became the "One." The secret of accessing business value through architecture is embodied in these keys.
I walked into the conference room at 8:00 in the morning, one hour before the meeting was scheduled to start. The LCD projector and screen were in place, but I needed an Ethernet cable to connect my laptop to the network; and, as expected, there was no Ethernet cable in the room. As with the LCD projector, I requested an Ethernet cable; but, as I expected, it wasn't there. I didn't panic, because I had an extra cable in my briefcase. I thought to myself that there was nothing that was going to stop my "wow-them" presentation/demo, and that these scientists would be eating out of my hand when this was over. I plugged the Ethernet cable into my laptop, connected it to the Ethernet port in the conference room, turned on my computer, and waited for the then-five-minute boot-up.
I guess you can imagine what happened next. Yes, you are right: I did not have network access. The network port was dead. Now, I started to panic. How could I do the demonstration without a live connection to the network? There were a few people in the Infrastructure department who owed me a favor, so I made calls—fast. The time was 8:40 and I had 30 minutes before I needed to be ready. I needed 5 minutes to cool down from the panic attack, another 10 minutes to find someone who had the authority to activate the network port, another 5 minutes to convince him the take my request, and 10 minutes to activate the network port. Yes, I know: People had started to arrive for the meeting, and I was now running late. Then it happened: The network was live and I was good to go. I took a handkerchief from my pocket, wiped the sweat from my brow, and heaved a huge sigh of relief.
It was 9:05, and everyone was very understanding. I first launched into the "wow demo." The audience was very interested at first, but I am not sure when it happened; they turned on me. They started hitting me with hard business questions—questions about problems that the application I was designing should have been able to address, but apparently did not. With the barrage of questions, and me stumbling over the answers, completing the demo quickly became a distant dream. Initially, I could not believe that they did not like the demo; but as I really, really listened to them, I discovered that although the demo presented a technologically innovative system, it did not support their business operating model.
The first two things that I started to think about were that I needed better requirements and better technology. I was still caught in the Matrix of "the latest and greatest," until I met Kyleel. He was one of those renegades: an architect. Most of the developers did not take architects seriously. They knew architecture was something that they needed to do in the course of developing an application, but it was never considered a craft unto itself. Kyleel was a true architect, one who was committed to the craftsmanship of system architecture and its direct impact on business operating models. After my most unfortunate demo, Kyleel asked me to come to his office if I wanted the "keys to the kingdom."
"What do you mean?" I asked.
"Come to my office at five o'clock to find out."
At 17:00, I was at Kyleel's office door, curious as to what insight he was going to bestow upon me. As soon as I was in his office, he wasted no time. He asked, "Do you want to have as much influence on our business as the business executive?"
"I don't know," I said. "I like just dealing with the technology. I don't like two-faced business politics."
He stood up from his desk and shouted, "Do you want to make an impact on the business, or do you just want to be an expense?!"
I wanted to affect the business. Kyleel, with marker in hand, approached his white board and began the process of giving me the "keys to the kingdom."
Key 1: Align Architecture with Business Strategy
"As an architect," he said, "you must ensure that your architecture is aligned with business strategy, for both the short and long term."
This was the first thing that my demo lacked. My audience did not see a business future for what I had created. The services that my solution provided were not aligned with the business's short-term growth, nor did it drive long-term business strategy.
Key 2: Create an Architecture that Is Executable
"Your architecture must be both buildable and runnable."
The technology position that I presented was clever, and supported an innovative methodology. However, my audience did not understand how this type of architecture could be implemented or supported by their business operating model. A model solution that cannot be executed is only an expense to a business. Current research [Ross, J. W., Weill, P., and Robertson, D., 2006] demonstrates that companies that have a solid foundation for architecture execution have lower technology costs; their products and services are delivered to market faster, and their overall profitability is higher.
Key 3: Create an Architecture that Provides Business Agility
"Your architecture must directly support the ability of your business to handle competitive pressure."
My conversation targeted the flexibility of my architectural solution, but showed little value as to how it would support the agility of the business. I failed to focus on how I could have supported specific elements of the business strategic plan. For an architectural solution to provide true business value, it must be part of the backbone of the business operating model.
Key 4: Create an Architecture that Is Cost-Effective
"Remember always the mantra of business: 'Increase profit and reduce cost.'"
This rule should not be disregarded or taken lightly by architects. Keeping the architectural solution at a cost in line with normal business operating cost is the architect's most important goal. Cost-containment strategies should be applied to implementation and scalability efforts, to support business agility. My presentation only discussed implementation cost, but it did not discuss cost of ownership or—most importantly—return on investment (ROI).
After a short pause, Kyleel looked at me and said, "Remember, the business value of your architecture is what you have to demonstrate to your audience."
I thought long and hard about Kyleel's message. Determined to make my next go at the presentation a flying success, I reviewed the corporate strategy, which was the culmination of input from several departments. I relied not only on strategy that was written down, but also on personal conversations with the executive-management team. Next, I studied the business operating model. I received input from both line and executive management. Throughout the entire process, I felt myself evolving from a technologist to an architect—fully aligned with the business. As I delved deeper into business processes and learned to use their language, I started to notice that business management was looking at me more as a colleague and less as an outsider. These interactions gave me insight into how I needed to align my architecture with the business (Key 1) and support business agility (Key 3).
Next, I needed to use Key 2 to ensure that the architecture had a foundation to support its implementation. For this effort, I collaborated with cross-functional teams and created a cross-organizational community of the practice for architecture. The foundation for the architecture environment would ensure that we had an executable architecture. This is a critical assessment that, if overlooked, could mean failure.
I had incorporated Keys 1, 2, and 3 into my work, but the key that would prove the ROI—Key 4—had yet to be used. This is never an easy key to use, because architecture implementation has many visible and invisible costs. These costs are not usually contained in only one group within a company, but can be spread across the entire enterprise. Enterprise-wide costs not only affect budgets in specific groups, but also affect group compliance to the proposed architecture framework. Two sure issues that will compromise compliance to any architecture initiative are the cost of implementation and the difficulty in using its framework. The best solution for our business operating model, from a technical point of view, was a service-oriented architecture (SOA) framework. I needed, however, to validate that framework from a cost perspective. I was to achieve this by defining a formal architecture engagement model against which I could validate all cost propositions.
The alignment of the architecture with the business operating model was complete. In addition, cost efficiency and business agility were confirmed. Not only could the architecture drive business agility, but management also had a full understanding of the value proposition that the architecture would bring to the business strategy.
- How can I unlock architecture business value across business models in corporate subsidiaries?
- What tools should I use to ensure consistent calculation of business value?
- [Ross, J. W., Weill, P., and Robertson, D., 2006] Ross, Jeanne W., Peter Weill, and David Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, MA: Harvard Business School Press, 2006.
About the author
Othel Rolle, PhDc, PMP, has 18 years of experience in defining and implementing software and data architectures for competitive healthcare IT solutions. He has successfully facilitated strategic partnerships between senior IT management and leading-edge technology companies, and managed cross-organizational workgroups to incorporate business goals and data integration in setting enterprise architecture standards. Othel has developed application frameworks for real-time data integration and designed semantic software solutions.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.