Rob Eguchi

Solution Architect, Prime TSR

For any Infrastructure Strategy to be successful, it is critical that enterprise architecture reviews of any system on the core systems roadmap, are done carefully, and strategically. 

A well-designed enterprise infrastructure strategy will include a solid roadmap of the core systems needed to achieve the company’s business goals as well as how each system should be analyzed to determine success.

It’s all too easy to get lost in all the possibilities of what could be built without careful consideration of, well, the reality staring them right in the face.

Instead, what we often hear from most IT and infrastructure strategies about is The “Ivory Tower” Approach: That point in the architecture review where the Enterprise Architect has engaged in “here’s everything we could do with the kitchen sink thrown in” thinking. 

The problem is, it doesn’t focus on everything that a team should do from a very practical standpoint. That’s why there’s a tremendous value in taking a far more pragmatic approach to enterprise systems architecture reviews for applications on the critical path roadmap. 

How Did We Get Here?

The “Ivory Tower” issue is actually a complex problem that many cultures struggle with. The root of the problem frequently occurs in an environment where every department has its own strategy. Yes, you can aim to implement a business strategy at the corporate level, but it’s the departments that will aim to navigate the direction in their own unique way. After all, they have their own targets to achieve, right?

It doesn’t help that corporate executives are rated based on their own individual performance. So as each department and executive engages in “Ivory Tower” thinking on the grand possibilities of what the system can deliver for them, all of these stakeholders understandably need to be heard. That said, putting together a solution that appeases all of them is quite a challenge.

Enter The Enterprise Architect – A Special One.

The Enterprise Architect, at his best, is a person who truly listens with “both ears.” In one ear, information is flowing in from the business (non-IT folks) in terms of what they truly want to accomplish and the EA has to listen intently to these needs. In turn, with the other ear, they’re listening for how they must translate this newfound knowledge of business wants back to IT so they can properly build and deliver what’s required.

What’s A “Must Have” Today And A “Nice To Have” For Tomorrow?

We know that everybody has a laundry list of things they’d like to see incorporated into a system’s architecture, but surely some of those items rank higher on the priority list too.

To uncover those priorities, having artful negotiation skills can pay off for the Enterprise Architect.

During upfront conversations, it can be learned that a department may need some essential elements to be incorporated into the system architecture today while some other elements can be built in later on down the road.

In actuality, what we’re really doing is making a decision based on what’s best for the company overall rather than one piece of it. We’re operating around what the corporate strategy is telling us to do. Not what one department is telling us to do. Yet, for each side that has to be addressed, we’re breaking things down for each department so it makes sense for their part of the world and they can see how they play a role in helping the big picture come together.

The truth is, it’s less about a technological discussion and more often a business outcome kind of discussion.

Starting With The End: What Business Outcomes Are We Seeking?

A fundamental element of having a more pragmatic approach to system architecture reviews is a deep dive into the details of the business outcome we’re aiming to drive through this system. Frankly, it’s fine and good to have a fancy-looking system, but if it’s useless to the business, only so much functionality is being executed upon.

That’s why a total, end-to-end look at the entire system is essential during every architect review. Where is the user touching the system now and is that a different point from where they’re actually supposed to be experiencing it? What is the outcome of that happening? It’s a big picture point of view when an EA begins reviewing the system, but in many cases, we’re about to move from that ultra-large perspective of a system to breaking it down into many smaller pieces of information – each and every one of which is easier to review.

Think of it like those times when you’ve put together a giant puzzle. On the table, you’ve got all of these little pieces to study carefully. You see how each one is shaped and fit them together, one after another until finally, you step back at your work and say, “Aha! I see how each of these form the picture now.”

A 360-Degree – And Long-Term – View

Part of building a system with such a variety of specifications means that we need to be concerned about all the types of users who could potentially interface with that system. For example, could the company’s Marketing Department use product information from the system to create a better marketing campaign?

This 360-degree view to appreciate how all parties will use the information helps a great deal in planning.

At the same time, while we’re planning around that end customer, the pragmatic view forces to continually ask questions for the long-term such as:

  • At what cost are we building this solution? Will that still be seen as a great value years from now?
  • Is the solution we’re building today sustainable for the organization’s strategic plans for the next three years? What about the next five years?
  • If market conditions should change unexpectedly, how might we evolve this system to accommodate?
  • What kind of built-in flexibility to make potential modifications is there beyond what the system provides us today?
  • What trends in the market or around the globe could alter user behaviors and preferences in relation to the system?

Collaboration Is Key

System architecture reviews aren’t always best left in the hands of one individual. The review cycle itself is changing to be a more collaborative effort because, in many ways, it needs to be. Different people on the team are subject matter experts, so even before a review can start, it’s crucial to get the point of view from many other team members.

Let’s not forget our business, non-IT users though, too. We prefer they have a seat at the table for planning as well because they can often see things from a particular angle that may not have been considered. They’re the users who are ultimately seeing and acting on the information, so why plan a system “in a silo” without their involvement and input?

As we involve business users in the review process, we have to picture all the potential scenarios for how they will utilize the technology at hand. There are a lot of “If this happens, then what happens next?” questions to answer. For example, if a user has a lot more data and more information than he previously had, will his speed of doing things using this system remain the same?

It’s a bit like a car manufacturer that considers all kinds of driving situations and then builds an array of technologies into the car based on those potential scenarios. The Enterprise Architect has to sit in that driver’s seat as they plan for the road ahead – including everything that the system could experience for the next several years. They evaluate these scenarios and then chart a course ahead that is rooted in a realistic response that provides a better, more satisfying user experience.

The balance we’re striving for is to minimize disruption to the business while realizing we are acting as agents of change. Perhaps what a company has been doing for the last five years isn’t fully optimized, so a change needs to be made. That change can come in the form of new documentation, teaching people how to handle new information in newer systems at a faster pace than before, even people being laid off or new people being hired that need to be trained on a new skill set. We can’t completely “upset the apple cart” of daily operations but we can’t maintain the status quo either – and that’s where a very pragmatic and methodical approach can ensure steady but manageable momentum takes place to move the company forward.

Let’s face it: Most people who have the title of “Enterprise Architect” didn’t start their career in that role. They started by learning a lot about the technology involved. However, it’s so important for an Enterprise Architect today to understand the business side just as much. What does the department head really looking for? How can we put the language of the technology so familiar to us in the kind of language that this non-IT professional can appreciate? When we can understand the true “ask” behind every stakeholder’s questions, we can provide technological planning and solutions that actually reflect their true business goals.

Yes, getting the organization on the same page today in that sense is obviously crucial to success. Yet the real “next level” in pragmatic system architecture reviews occurs when an Enterprise Architect is also considering the reality of tomorrow’s trends and user behaviors.

Can we assume that what worked before will continue to work just as well five years from now? No. Rather than looking back, when the Enterprise Architect looks forward and considers all the potential market trends, global trends and user preferences that could very realistically evolve, they’ll be planning in a far wider but still pragmatic perspective – all while avoiding planning from The Ivory Tower during their architecture reviews.

The pragmatic approach to system architecture reviews can ultimately achieve a win-win: The kind of system that’s technologically stronger but one that can also evolve with the ever-changing goals of a company and its users.

Enterprise Architecture