Building an Enterprise Architecture: Principles

Intkhab Ali, Senior Solution Architect

March 09, 2019

The Head of Architecture Meets Her Team

Carmen looked around the table at the gathered architects. Some were domain architects, some solution, and the two to the right of her were the only Enterprise Architects. It was 11:00 AM and time to begin. The last person to walk in was Ezra, a solution architect and he closed the door, sat down, and stared across the table at Carmen and the two EAs flanking her.

This was Carmen’s 3rd day on the job as the Head of Architecture. She’d already met the two EAs. They had spent the past two days introducing her to all of the people around the table but she’d already forgotten many of their names. Technically, only the two EAs reported directly to her, but there were dotted lines to all of the people here – and a few more at other locations.

She thought about the CIO’s words on the day she started: “This company has functioned without architecture for more than 20 years. A unified one that is. Every architect here kind of has their own job description and their own opinion of what architecture is.”

Carmen had smiled inwardly at that one. Larry the CIO would be very disappointed if he thought he would be changing that.

“If you can think of an IT bad decision that could have happened in the last two decades, we’ve probably done it. Our technical debt is crazy and we’ll probably never fix it. Almost better to throw it all away and build it all new. Maybe the cloud will be the opportunity to do that.” Larry, already looking weary, then glared at his phone which had started ringing. “We’ve had fits and starts with architecture but I finally stuck my neck out and got funding for you,” he said as he reached to pick up the phone.

The Architecture Team Identifies the Problems

After a few introductions and sharing a bit of Larry’s expectations with the group, Carmen then stood up in front of the whiteboard, marker in hand, and said, “I have my own vision of what the Enterprise Architecture function will look like, but I want to hear from the folks here that have been in the trenches. What are some of the problems here?”

It was like dropping a match into a vat of explosives. Carmen was eventually able to steer the opinions, war stories, rhetorical questions, and complaints into a list on the whiteboard including the following items, many of which she’d seen before at other companies.

1. 1. Business units are out of control and select tactical products.
   2. We have multiple, overlapping solutions for the same problem space (we have 3 email systems!)
   3. Management seems to change their mind at the drop of a hat.
   4. Some of our IT folks seem anchored in the past. As do some of their customers.
   5. Our systems are very proprietary and changing them is like neurosurgery.
   6. Architecture isn’t respected. Decisions aren’t made from an architectural perspective.
   7. IT is reactive rather than pro-active.

There were several others, but the above list captured the most common.

The Architecture Team Brainstorms Potential Solutions

Carmen looked around and asked, “What are some things that we can do to solve these problems?”

After a brief pause, many suggestions were thrown out including:

• • Formalizing the architecture practice.
  • Getting a stronger IT leadership (which was quickly dismissed by most architects)\
  • Building an Enterprise Architecture practice

More came out but Carmen stopped the discussion when Ezra piped up amid the hubbub and said, “Standards”.

Carmen’s head snapped up and she held up her hand until everyone stopped talking. “Ezra,” she said, “what do you mean?”

Ezra at first looked around the room hesitantly but raised both his head and voice, “We’re missing a coherent set of IT standards.” He hesitated and waited for the room to react. When nobody said anything, he continued. “We always criticize everyone about their decision making whether it’s a new product, another system, or some shiny new technology. But we really have no basis to do so.”

“Wait a sec,” chimed in Josephine, the network architect. “We have lots of standards. Nobody gets to use their own database or, God forbid, network unless it goes through us…”

“I know. I know,” said a now more energized Ezra.” But it’s only in some areas and not others. In infrastructure we’re pretty good. Not perfect, but pretty good. But not in the solution space. We don’t have standard solution patterns for applications. We have no process in general to deal with exceptions, and most architects outside of the infrastructure and data architects just try to do what the business wants and it just makes them a hero to the customer at the expense of corporate architecture.” He pointed to Kamil, a security architect and said, “Meanwhile people like Kamil just look like roadblocks. I’m guilty of it myself. I’m not rewarded for enforcing good corporate architecture. I’m rewarded for delivering a solution that meets the business requirements….and yes, I feel guilty about it all the time. But the business loves me.”

At that the hubbub started up again as many architects burst into conversations. Carmen looked around for few minutes before raising her hand again and waiting until the silence settled back into the room.

EA vs ea
Ezra is onto something,” she began as she surveyed the room, “but he’s not going back far enough.” She let that sink in and looked expectantly waiting for someone to pipe up. After a few silent moments of waiting, she sighed and continued talking. “You’re all absolutely right in listing out the problems and potential solutions. We need to start building a “real” enterprise architecture. And by that I mean a lower case ‘e’ and lower case ‘a’ enterprise architecture.”

She noticed quizzical looks from most of the attendees but a few like Ezra were nodding. “Look folks, nobody here is opposed to corporate or enterprise architecture, but EA has gotten a somewhat bad name in recent years. I’ve been in companies where they’re described with terms like ‘dreamland’, ‘ivory tower’, ‘idealogues’, or, my favourite, ‘architecture astronauts’ with their heads in outer space.” She noticed some smiles and nods around the group.

“We tried that here already,” said Joan who was one of the other solution architects. “I used to be part of the EA team here. We started to build the practice, produced a whole bunch of shelfware, and then we were disbanded as soon as the CIO changed. Many of us went and got TOGAF and everything, which we try to apply, but it seems like an uphill battle.”

Carmen nodded. “I’ve worked for many companies that either try and fail with EA, or just limp along and in some cases just end up redefining the role to be something like a “solution architect on steroids” or some incarnation. But we all know what the promise of enterprise architecture is and we’re all drawn to it without fully understanding what ‘it’ should be.” She let that sink in before continuing. “Look, in most companies where EA as a formal team has failed, there’s going to be skepticism about it. Forming a new EA (uppercase ‘E’ and uppercase ‘A’) team is not going to succeed unless it gets a ridiculous amount of organizational commitment from senior management. That only seems to happen when a new visionary leader comes along or there is a portfolio disaster that needs cleaning up. Even then, it’s not always sustained.”

“I’m going to suggest, my dear colleagues, that ‘ea’, lower case, is much more important in the short to mid-term than ‘EA’, upper case, if we hope to succeed in getting our architecture act together.”

Joan piped up again and said, “I think I know what you mean, but let me state it again and see if you agree. What I think you mean, and I agree if it’s true, is that ea is the responsibility of everyone at this table – both to start it up, but also to sustain it.” She looked around to see if anyone had any contrary opinions. “That’s what failed last time. Top down didn’t work for us as it was too removed from actual implementations. Yes, it would eventually work its way down to guidance for solution and technical architects, but we didn’t have enough time to wait. Organizations are impatient and have other things to do.”

Carmen started getting more animated at this point. “Exactly! Particularly when the first kick at the can has failed, it’s up to the rest of us to be a virtual EA. Yeah, I’m an EA as are Chris and Ricardo, but we will fail unless the enterprise architecture is driven by all of us. That’s where we need to start.” She got up, took the whiteboard marker over to Ezra and handed it to him. “So Ezra. What’s the next step? It seems to get down to a starting point we can all align to. What are we missing?”

The Importance of Architecture Principles

Ezra stood up and wrote “Standards” on the board. Then he crossed it out and right above that wrote “Principles” with a large circle around it. He looked at Carmen who nodded encouragingly. Ezra started speaking. “We’re so focused on things like standards that we seem to miss that standards are developed over time and are subject to change….but we’re not even consistent in understanding our Corporate architecture principles so we have the same rules in guiding our architecture.”

Carmen pointed to the problems and started speaking. “Look at problems like the company being all over the place on decisions and the business acting like their own mini domains. There are no EA principles that explicitly give us an architecture basis to challenge decisions. Or even drive standards.” She tapped her finger on problem 2 – the one about multiple overlapping solutions. “We clearly all believe that three e-mail systems is bad, but where is our documented principle of re-use or portfolio rationalization that helps inform the decision making to either not implement a new system or rationalize existing systems? Yeah, that’s probably two principles. We have none that I can find right now. Believe me. That was the first thing I looked for.”

She saw people look at each other and slowly nodding as the acknowledgement started to come to them. She continued. “We as de-facto and actual enterprise architects have to agree on a set of rules that guide our decisions…no, that anchor our decisions. Then we need to get the senior leadership to agree to those rules, sorry principles. Believe me, it’s much easier to get senior leadership to consult with and agree to a dozen or less enterprise architecture principles than 380 technical standards.”

Someone, Carmen missed who, said, ”But we have standards and we still need them!”

Surprisingly, Joan jumped in. “Yes, we need standards, but we don’t need a full repository of standards right now. We already have standards in some areas but it’s much more natural to build standards organically, through day to day architectural decisions and through research and planning of upcoming standards needs. As I see it, where we are is at the start of a new journey to build an architecture standards base. But for it to stick, we need to deliver principled architecture so that every standard we decide on is…” She paused to look at Carmen before continuing, “anchored.”

The next 15 or so minutes was everyone talking to seemingly everyone else about standards and principles. Carmen herself got caught up in the discussion before she looked at the clock and decided she needed to move the conversation forward.

“Team,” she started. “I’ve been asked to drive architecture forward in the organization and, more importantly, make it relevant. Once we achieve relevance, we can start to get teeth. What could be more relevant than helping the enterprise get to a common architectural decision-making set of principles that can help drive decisions.  And, since this is key, highlight discordant decisions?” The question was rhetorical and she took some pleasure in believing her first challenge with her new team was one they’d be willing to take on.

She then grabbed a whiteboard marker and asked, “What are the architecture domains?” Responding to various voices in the group, she wrote down 5 headings across the board.

Kamil had insisted on the last column but most architects didn’t seem to have a problem with that.

“Most of you already have principles that you use in making your day to day architecture decisions,” Carmen explained as she was writing on the board. “For example, under the information domain, I think we can all agree to a principle around one version of the truth.” She then wrote Use only preferred/standard technology under the Technology column. “There are of course more under each of the domains. Before our meeting next week, I want you all to go away and think about at least two or three principles for each domain, and we can put the candidate principle list together. And by the way, I don’t want just a one-line principle. I want to see, for every principle, a name, a description, and bullet points of the implications. That is, how will those principles be applied to help decision making or what effects will they have on the decisions made?”

Carmen then walked to the leftmost side of the whiteboard and added another heading: General Principles. “When we go to senior leadership, I want a dozen or fewer general principles that apply across domains. We’re going to agree on a candidate list of General Principles first, which is what I’ll get the senior leadership to review and approve. I’ll start the list for you.” She continued writing on the board.

“The second General Principle,” she explained, “has to do with a corporate stance of making decisions that look to the future and not just the past or present. It actually has a few implications. For example, it tells us that we prefer solutions that don’t just answer the immediate needs, but have an eye to what’s required for the future. A second implication is that our architecture practice, if not the company as a whole, must look to the future. We need to anticipate technology and other environmental factors in our decisions and activities. If that means we need to familiarize ourselves with emerging technologies, then we must be aware of technology trends according to this principle.”

Getting Management Buy-in

As the meeting was nearing its end, Carmen offered a final nugget before sending her architects off to their homework. “In my experience, it’s not difficult to get senior leadership to buy into sound architecture principles. Most of them can be linked directly to the mission, goals, vision, and values that the business has invested a lot of time into.” She then smiled mischievously at the group. “Also, once we get their buy-in followed by a few examples of us actually using the principles, it’s a lot easier to challenge them using the same principles when they start to inevitably drift off course.”

As the architects started leaving, sharing their own pet principles with each other, Joan walked up and said, “It sounds like you’ve done this before. I can actually see a path to success here.”

“I think so,” said Carmen. “It’ll require commitment from all of us here, but the investment will be worth it. Enterprise architecture is a multi-year journey and we fail because we try to hammer it in to an organization that isn’t really, truly sold on its benefits.”

Carmen left the meeting last as she was still clearing the whiteboard, but she was cautiously optimistic. She might have even been humming a cheerful tune as she headed towards Larry’s office for an update.