Image source: Leveraging Corporate Responsibility

We’ve shifted this week to study and discuss the Future-State of the Enterprise Architecture: basically how we envision the organization functioning at the end goal of the EA Initiative. Documenting the future-state is one of the primary steps in the Analysis phase of the EA Implementation plan, as is documenting the current-state.  Common sense would tell us that  we “know” what the current-state is so it should be easy to document that first and then work towards creating future-state artifacts later as the implementation plan and vision  are finalized.  Yet, Gartner strongly suggests that the current-state documents should be low priority and the future-state vision should be top priority.  “Creating an inventory of the current-state EA is a low-business-value activity. The business value of EA is based on the insights into how the organization must change.” (Burke, Papegaaij & Guevara, 2011)  The apparent issue lies with the fact that many EA teams get stuck on making the current-state artifacts and components “perfect” which ultimately wastes time because it brings little or no value to the organization.

The recommendation, then, is to look forward first and let the vision of the future guide the entire process.  This may seem odd to us since we are “in” the current-state now and it would seem useful to have the information readily available to us as reference.  But I think the pitfall lies in knowing what particular information is needed from the current-state.  How do we know which information is applicable?

It’s hard to picture this type of forward thinking activity in our daily lives, but that is because technology nowadays provides us with so much information that never was previously available to the typical person. Using the metaphor from the last few posts, let’s consider the endeavor of a long journey.  Today, we can throw a few things in our bag, toss it in the car, program in our GPS destination and off we go.  Even for international travel, the steps needed are minimal in most cases.  But instead, think back to the 1400s and 1500s during the time of the Age of Discovery.  It was not a simple process to gather provisions for a year long ship voyage across the Atlantic Ocean with the hope of sailing west to India (as in the case of Columbus).  The personnel, supplies and planning needed for such an under-taking was tremendous. And depending on where you were planning on going, the preparations could be completely different.  Was it a known trade-route down the coast of Africa or east to Asia?  Or was it an unknown venture west?  You didn’t just pack up the ship with random supplies and then decide on your destination.  The expedition planners needed a end-goal in mind when coming up with plan for the voyage.

Ultimately, even with all the planning that was needed for a successful voyage, Columbus’s First Voyage was technically a failure.  The future state that he envisioned was a successful journey west from Spain to establish a lucrative trade-route with mainland China.  However, as we know, he never made it past the  Caribbean Islands.  The successful voyage west to China didn’t happen until some 20 years later, led by Magellan.

Image source: www.columbusdiary.info

References:

Burke, B., Papegaaij, B. & Guevara, D. (2011) Enterprise Architechture Program Pitfalls: Don’t Start With the Current State (G00210232). Gartner, January

#ea872 #lifeisajourneybutthedestinationisimportant

Image Source: Pinterest

Last week I talked about EA Principles and how they help in the decision making process. We establish a “boundary” by building guidelines based on existing business strategies and requirements. This concept of the combination of business strategy, environment & market trends, and requirements in which the business normally operates is frequently referred to as the Business Context.  This is our perspective on how the business operates and its’ driving factors.  And like the above graphic, if we are not careful with examining the full context, we can have a skewed perspective on the nature of the business.

From the specific viewpoint of Enterprise Architecture, the Business Context provides a “strategic alignment with the business and a focused direction of effort” (Burton, Allega & Lapkin, 2009).  This context provides the enterprise architects with the proper frame of reference in which to link together the EA Principles, Business Strategies and Business Initiatives. This brings cohesion to the EA Implementation Plan and allows EA to work toward bringing value to the organization.

As we continue along the path we started last week, we use our Business Context to help in our navigation of the unclear path laid before us.  We have our origin point (current state) and our destination (future state) mapped out before us.  The EA Principles are the guideposts along the way that help us to successfully stay on track as we make decisions along the way. Now, we add in our Business Context which acts as an “absolute” reference point to further clarify our navigation of the path. Just as in the case of navigating with a map or a GPS system, if we do not have an understanding of where North is located, then the directions along the way will not make sense.

Image source: Openclipart

#ea872 #context

References:

Burton, B., Allega, P. & Lapkin, A. (2009) ‘Business Context’ and ‘Business Architecture’ Are Not the Same (G00170922). Gartner, November

As we travel down the path of Enterprise Architecture, there are various times when important decisions must be made.  Hopefully, we have a tool that will help us make those decisions that is a little more clear than the signpost shown here.  But there are many times, not just within the scope of Enterprise Architecture, that we come to a decision point, and we are either presented with poor information or no information at all.

How do we overcome this challenge that, at times, appears to be fated to fail no matter how hard we try to succeed?  Or we can make what appears to be a good decision at the time, but then we start to doubt our choice as time goes on.

Image Source: Wikipedia

I ran into a situation like this while on vacation a few weeks ago. My wife and I were up in Upstate NY along the edge of Lake Ontario.  As we were driving east from Niagara towards Rochester, our GPS map directed us to take the ramp onto Lake Ontario Parkway.  It seemed like a good idea as it appeared on the map to bypass a lot of local traffic, so we took the ramp and got onto the parkway.  However, very quickly we started doubting the wisdom of that choice.  The road was an old concrete highway that had many patches and potholes.  We drove for at least 10 minutes without seeing another vehicle on either direction!  Frankly, I had started to wonder if the road was really still in use when we saw another vehicle coming the opposite direction, and eventually the road surface improved.  In reality, the route was an excellent choice and saved us a lot of time; however, the western portion of the parkway is in serious need of repair and apparently is a topic of some contention for the locals.

We clearly had a tool that was guiding us towards making an intelligent decision, yet we immediately started doubting the choice.  And I am sure we have all had the occasion where our GPS system gave us poor or even completely wrong directions.

In the business, technology and Enterprise Architecture worlds, the same situation can occur.  There are tools available to be used which assist in decision making.  It is up to the user to properly weigh the guidance of the tool and decide on the right course of action.

In this past week’s group assignment, I happened to pick the Enterprise Architecture Principles artifact to study and analyze.  This is a perfect example of a business tool used to help in the decision making process. According to TOGAF definitions, Enterprise Architecture Principles “define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise and form the basis for making future IT decisions.” (TOGAF – Architecture Principles)

So we establish a set of guidelines to help us measure and test all decisions that are made.  A “measuring stick” per se. Yet, the creation of these guiding principles itself is a large challenge.  If the principles are too broad, then every decision could be made to fit the proper criteria.  If the principles are too narrow, the business will be in a bottleneck as decision making would have to be inspected with a magnifying glass to assure if it meets all the rigorous criteria needed.  We are stuck between the loose suggestions versus the rigid laws.

By building our guidelines based on existing business strategy and requirements, we can establish an ideal “boundary” for any decision making activities. Only by establishing this business context do we have clarity regarding the proper application of the guiding principles.

By successfully navigating the twists and turns of our complex business strategies and environments, and confidently relying on the tools we are provided, we can successfully reach our final destination.

#ea872 #guideposts #lighthousesoflakeontario

Charlotte-Genessee Lighthouse, Photo credit B.Albright

Image source: Bigstock

Last week, I talked about the importance of establishing a firm foundation on which to build the EA program. Easily half of the key points of that “cornerstone” are directly related to dealing with people: growing support, establishing credibility, and building a rapport.  While Enterprise Architecture is technically a systematic approach to the linking of business, strategy and technology, in practicality, EA is a lot about managing change and influencing the perception of people in the organization.

According to Deborah Weiss, “a truly effective EA team must be able to have an organization-wide impact, regardless of positional power; this can be achieved through increasing influence and personal power. (D. Weiss, 2005)”  In order to gain the buy-in and confidence of our stakeholders, enterprise architects must concentrate on the people aspects of the organization as well as the technical and strategic aspects.

Some suggestions from the same article:

• Speak the language of stakeholders
• Create a favorable impression
• Negotiate and bargain
• Become more personable/likable
• Get to know your stakeholders personally

These are all positive actions. Yet, we typically don’t associate them with business strategy or technical systems.  We always need to keep in mind that behind those business processes and technical systems, there are real, live people with whom we can make a connection and potentially win their support and trust.

By building a rapport with our stakeholders, we gain support within the organization, establish our credibility, and we can start to clearly identify and meet the needs of those stakeholders. This is not only good for the EA program, but for the organization as a whole.  It is important that we realize this is not a one-time effort, though.  Throughout the life of the EA program, there must be concentrated effort to have clear communications with all the different levels of stakeholders.  Only in this way will the EA program continue to have a positive impact on the organization.

#ea872

References:

Weiss, Deborah (2005). Winning Friends and Influencing People in Support of Enterprise Architecture (G00134689). Gartner. November

Image Source: Great Philadelphia Church (Emanuel Evangelical German Lutheran)

In today’s world of construction, the concept of the cornerstone has mostly lost its significance.  If there is a cornerstone as part of the construction of a building, it is typically an ornamental piece, simply commemorating the construction date.  At times, it is even used as a time capsule of sorts.  However, in the years past, the cornerstone held a much more pivotal role in the entire construction of the building. “The cornerstone is the first stone set in the construction of a masonry foundation, important since all other stones will be set in reference to this stone, thus determining the position of the entire structure.” (Wikipedia)

Nowadays, with all of our sophisticated tools, equipment and software, there is little need for a physical reference point being embedded into the foundation of our construction, even though physical markers are still used at the beginning phases of the construction of modern buildings.  Yet the concept of the cornerstone, or an absolute anchor point, is still a fundamentally important part of the building process.

Last week, I talked about building a foundation.  There is an important need to “right-size” your EA program at the beginning so that it will progress smoothly and start producing recognized value from the beginning.  However, through this week’s readings and the sample presentation, it was clear that it is just as important to establish the right support structure within the organization.  During the launch of the EA initiatives, we need to carefully build the “cornerstone” of our EA foundation:

1. Identify the key stakeholders from within the organizations leadership, as well as other levels of the organization, who will support the initiative.
2. Establish the credibility of the EA initiative upfront, gaining the buy in of our key stakeholders and business leaders.
3. Build a rapport with other departments within the organization, so as to establish cooperation instead of competition.
4. Develop a clearly defined road-map from the current state  to the future state of the organization.
5. Create a distinct list of expectations, metrics, principles, strategies and key roles that will be used throughout the course of the initiative which will set goals for the EA team to work toward, but also allow progress to be measured.

By working toward a successful initiative launch, we establish our “cornerstone” which establishes a firm and distinct foundation for the entire EA program.

#ea #ea872 #foundations