Architecting Enterprise Transformations by Done Suresh;

Author:Done, Suresh; [Done, Suresh]
Language: eng
Format: epub
Tags: General Fiction
Publisher: Advantage Media Group

CHAPTER 7

LEVELS OF ENTERPRISE ARCHITECTURE

One thing about being an Enterprise Architect is that it is certainly never boring. Every organization is different in structure, mission, and the problems they are facing, which makes every EA project a new challenge. Part of this is because, depending on which part of the organization someone belongs to, they will have a different perspective of the process.

Perhaps you have heard of the old analogy of three blind men being asked to describe an elephant. One examines the trunk and says, “This creature has very long, flexible limbs.” Another examines the foot and says, “No, this creature has very heavy, large limbs.” And the third examines the tail and says, “No, this creature has short, thin limbs with hair.”

As I mentioned in the last chapter, this is why it is so essential for there to be input from stakeholders across the enterprise because CXOs will have one view of the enterprise, department directors will have another, and lower-level employees will have another. Bringing all of these perspectives together, with input from every level, creates a fuller, more holistic picture of how the enterprise can be optimized.

Understanding the responsibilities and expectations of each level of the enterprise is helpful, though, since they must all work together for transformation to be successful. Before we can discuss the levels of EA, though, we first need to discuss architecture partitioning, which is a technique for dividing the architecture across four dimensions:

• Breadth: The number of business units to be impacted by the architectural transformation

• Depth: The level of detail required (Strategic, Segment, Project)

• Domains: Business, data, application, technology

• Time: Length of time needed to achieve the Target Architecture

Typically, this partitioning process will occur at the very beginning of the architecture initiative in order to better manage the pieces. The EA Board will play the lead role in the partitioning process, using the outputs as a guide for determining the approach and action steps with minimal risk.

With a big initiative like Southeast Regional Bank becoming a one-stop shop, the partitioning process was key in preventing the phases and implementation from becoming unmanageable or more cumbersome than necessary.

In their situation, the breadth was fairly simple to determine because all of their business units were being impacted. That may not be the case in your enterprise, especially if you’re approaching a process Baseline First. The depth relates directly to everything we’ve already discussed with the levels of architecture within the enterprise and how high level or granular each initiative needs to be. The domains serve as a guide to ensure all aspects of the transformation are being covered within the EA process: How does the initiative transform the business? What data is being utilized? What applications are needed for optimization? And what technology will bring it all together?

And finally, what does the timeline look like for accomplishing the initiatives, and in what order do they need to happen? This goes back to the process of roadmapping and prioritizing the specific initiatives in a way that will mitigate risks and make the process more efficient without sacrificing quality.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.