4. Can your domain expertise hurt you?

This seems to be an absurd statement but think about this problem from outside IT: A jet bomber streaks across the sky of a friendly city. Its bomb bay doors are open; a live bomb is loose inside; it is armed and unattached from its mountings. At any moment the bomb can simply fall from the bomb bay and devastate the city. What prevents this from happening? Think about it and we’ll get back to it later.

TJ and I notice in our teaching that the in-person classroom sessions tend to be pretty lively. A small handful of students ask questions which seem to serve two purposes. First, they seem to need more information to integrate the learning with their ways of remembering things. This is good. Second, they are looking for creative ideas they can use to introduce some of the concepts to their organization. This is even better (as long as they pass their exams).

We know from the questions and interactivity that our students are capable of understanding the material and functioning as Enterprise Architects.

Things change slightly when we do the exercises. At several points during the classes we break into small groups to work through various exercises related to the material. There are no wrong answers, just a sharing of information among the groups.

In one of the exercises the organization and all of its problems are discussed. The list of woes is fairly short and touches on issues like losing big customers, software transaction problems, data inconsistencies and an excess of data centers in the organization. The groups need to identify the key problems from the pile of issues and then suggest who the key stakeholders are that relate to the problems they have identified.

Domain architecture shows up when people say that multiple redundant data centers are the main concern of the organization. This is an issue, but the organization isn’t making much money and they’re losing their largest customers. Is there something else that’s a bigger issue?

When you work within a single domain, such as applications, data, technology or business processes, you can focus on the issues that best support the delivery of service in that domain. Better networking supports better technology service delivery regardless of whether it contributes to the overall effectiveness of your business. It might or it might not improve business effectiveness.

When you work as an Enterprise Architect you may need to identify more than one opportunity to improve service delivery from one or more architecture domain. The art of Enterprise Architecture is in the ability to pick the opportunity that best supports the overall business in its quest to deliver good service and create the desired outcomes of the businesses’ strategy.

Having deep experience in a single domain can be an asset and an occasional liability. The liability emerges when the Enterprise Architect seizes on the brilliance of their decision based on that deep knowledge without fully considering opportunities in other domains. As an Enterprise Architect you’re no longer the smartest person in the room. Consulting with other domain specialists becomes more important in the decision making process. Good decisions become a process of wiggling the variables to see which ones contribute the most to achieving the identified objectives.

Back to that airplane in the first paragraph: You might have jumped immediately to the answer; many kids do; many adults do too. If you’re a pilot who understands the forces of lift, acceleration and drag on the airframe you probably have an idea but can’t express it verbally. Your answer might be something about a parabolic trajectory with a constant rate of centripetal acceleration along the … blah blah blah. Actually it’s simpler than all that. The plane is flying upside down.

Think about this next time you’re stuck between several possible best choices. You don’t have to be the smartest guy in the room. Expertise is all around. Just ask for help. The answer is out there.

www.WindsorCorp.com/BuildingEA

Posted in Enterprise vs Domain | Tagged , , , , , , , | Leave a comment

3. What is the Enterprise Portfolio?

I was talking with the CIO (let’s call him John) the other day and he was focused on application portfolio management. He was concerned that his application portfolio fell short of what he really needed. He thought he needed an enterprise portfolio management approach. He knew that the information in the current applications portfolio only told a small part of what was going on in his IT shop. He said he wanted a more comprehensive picture of all of the moving parts in his organization and how they were interrelated. He knew that everything had to be tied back to the business processes and focused on the business need.

John understood that the business processes drive the applications, data, and technology under his dominion.  These business processes delineated the services and solutions John’s shop provides. He realized the answer to his problem was to use an Enterprise Portfolio Management approach. This approach  integrates the vision of how everything connects and is traceable to the business processes. John’s organization provides a wide variety of services to its customers.

These business processes were not well documented. Each of the business managers knew their processes but this information was not shared nor available with many people. John told me he read our book Building Enterprise Architecture. He was enlightened because it gave him a roadmap to solve his dilemma.

We show that organizing architecture domains (business, applications, data, and technology) into information layers with the appropriate metadata, an organization can represent a complete vision of the business services being delivered through technology. The business processes are modeled in the business layer. The applications supporting each business model are linked to the appropriate places in each of the business processes. The data is cross-referenced to all of the appropriate applications. All of these interconnected systems are associated with the appropriate technology stacks. This enterprise portfolio approach is called ERAM (Enterprise Resource Allocation Management).

ERAM provides the single common vision needed to understand the enterprise portfolio and communicate business process, application, data, and technology and their interrelationships to business and technology leaders alike. A single page high-level model of the business and its supporting technology is now available for the entire organization. This vision facilitates effective resource management and planning.

The business and technical teams throughout the organization now have access to information on all systems. This information allows leaders to better understand existing business capabilities and quickly identify where redundancies are across the enterprise. Life suddenly gets a whole lot better. Opportunities for lowering cost and conducting business more effectively begin to unfold.

ERAM provides the single common vision needed to understand the enterprise portfolio and communicate business process, application, data, and technology and their interrelationships to business and technology leaders alike. A single page high-level model of the business and its supporting technology is now available for the entire organization. This vision facilitates effective resource management and planning.

The business and technical teams throughout the organization now have access to information on all systems. This information allows leaders to better understand existing business capabilities and quickly identify where redundancies are across the enterprise. Life suddenly gets a whole lot better.

www.WindsorCorp.com/BuildingEA

Enterprise Portfolio

Enterprise Portfolio Interconnection Relationships – Single Common Vision

Posted in EA Overview | Tagged , , , , , , , | Leave a comment

2. Does your SOA wiggle?

The other day I was driving somewhere and listening to the local public radio station as they interviewed Garth Sundem, author of “Beyond I.Q.: Scientific Tools for Training Problem Solving, Intuition, Emotional Intelligence, Creativity, and More.”

During the interview he held up the observed and measured example of problem solving approaches between Physics students and Physics professors. Apparently professors solve problems more slowly than their students. That said, they also seem to be able to solve much more complicated problems than their students. Researchers say this is because they don’t jump at the answers like the students do.

Professors tended to work at the problem in a more deliberate way. They tend to ask “What are our assumptions and which of them are true?” This process allows them to, as Sundem puts it, “Wiggle the assumptions” in a methodical way to determine which ones might be relevant to the results.

I found this a striking way to describe much of what goes on in the senior levels of IT and, in a big way, in the field of Enterprise Architecture. We avoid jumping to the answers and concentrate on wiggling the assumptions to make sure that the ones that affect the results are properly addressed.

In writing our book Building Enterprise Architecture, we discussed a variety of different aspects of IT that relate to Enterprise Architecture. None were more hotly discussed among our readers and editors than the subject of SOA (Service Oriented Architecture).

I started the early chapter drafts with long explanations of where SOA came from, what preceded it and how SOA isn’t real. This wiggling of assumptions made most of the editors pretty uncomfortable with what was being said because, in their direct experience, they knew of countless organizations that use SOA.

The SOA chapter is important to Enterprise Architecture and is, admittedly, widely used. The chapter in the published version of the book is short. We discuss the relationship between SOA and ERAM and show how to use metadata to identify SOA use and candidates for SOA expansion in the organization.

The chapter ends with 15 different definitions for SOA we sourced from 11 different IT vendors, consultants, researchers and industry consortia. We don’t have time to list all the definitions here. You can refer to the book if you’re interested or maybe even drop us a line politely requesting the list. No two of the definitions are alike.

The unstated suggestion is that the organization needs to create an agreed upon definition of SOA and make sure their trading partners and contractors understand what they mean by SOA. Given the cost and consequences, this is one of those variables that shouldn’t be allowed to wiggle.

www.WindsorCorp.com/BuildingEA

Posted in SOA | Tagged , , | Leave a comment

1. Enterprise Architecture from the beginning…

Jim and I published this book six months ago and we have been amazed at the resounding response received.

Building Enterprise Architecture began by combining and assembling several consulting projects into a set of best practices lauded by C-level executives. The strongest frameworks available are generally effective in providing generic guidance on enterprise architecture process, framework, and methodology. These frameworks fall short of actually showing how to put their processes into practice. This book addresses how to do enterprise architecture and what it looks like once implemented.

As the architect journeys down the road toward better design and greater efficiency, they are limited by existing organizations, environments, and procedural boundaries. They realize their goals are to provide better designs based on the strategic business goals from the enterprise perspective. But starting and improving the existing architecture practice is a significant challenge. Culture change, maturity, accountability, and building the common vision all have to be addressed. This takes leadership, statesmanship, and salesmanship skills. And this starts with winning sponsorship with executive leaders in the organization.

Enterprise Architects – A new secret weapon in business
Savvy organizations know that Enterprise Architects enable outcomes. This formerly tactical IT job is today a strategic position. Enterprise Architects increasingly report outside of IT to the CFO, CMO or office of the CEO. Enterprise Architects work in the zone where business capabilities are born.

Today’s CEO’s often collaborate with Enterprise Architects in evaluating short and long term strategies. Enterprise Architects continuously blend business and technical capabilities to meet the ongoing needs. If it sounds like ninja smoke…. It is and it works.

Most good C-level executives are Enterprise Architects whether they know it or not.

In our next blog, we will review some of the basic ways leading up to establish a common vision in your organization. We will also review the importance of continuous demonstration of enterprise architecture value to the organization and its vendors.

www.WindsorCorp.com/BuildingEA

Posted in EA Overview | Tagged , , , , | Leave a comment