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

When I decided in the Spring to embark on the journey of obtaining my Masters Degree, I spent quite some time researching the different fields that were possible options.  One of the key requirements was the need to be completely virtual, as it would be practically impossible with my work schedule and business travel to be able to attend a live classroom program, let alone finding the right program within a reasonable driving distance.  After a lot of research into different programs and different schools, I finally choose the MPS in Enterprise Architecture program from Penn State’s WorldCampus (online school).  MPS stands for Masters of Professional Studies, which, compared to a typical Masters of Science degree, is more practical versus theoretical in nature. (https://en.wikipedia.org/wiki/Master_of_Professional_Studies).

What is Enterprise Architecture and why is it important?

So lets first define what Enterprise Architecture is not:

While that may be an architectural diagram of the Starship Enterprise, it is not what I am studying….   (even though spacecraft engineering and design would be really cool…!)

So, then, what is Enterprise Architecture (EA)?

Here are some more formal definitions found from a few organizations:

• Gartner – Enterprise architecture is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. (http://www.gartner.com/it-glossary/enterprise-architecture-ea/)
• MIT Center for Information Systems Research – The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. (http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/)
• Microsoft – An enterprise architecture is a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change. (https://msdn.microsoft.com/en-us/library/ms978007.aspx)

The easiest way to describe EA is the intersection of Business, Strategy and Technology:

As we studied in our previous class (EA-871), the foundation of Enterprise Architecture is that it holistically links strategy, business and technology.  From a top-down perspective, EA helps to ensure that strategy drives business and technology planning.  From a business perspective, EA provides the context and purpose of business activities by ensuring technology is implemented only after business requirements have been identified and defined. And from a technology perspective, EA provides the strategy and business context for resource planning (Bernard, An Introduction to Enterprise Architecture, 2012).

So what now?

As I read through the course materials for this week, a couple of statements stood out.

1. “Building a foundation is not a quick or easy process.”
2. “EA is a process of progressive decomposition. A best practice is to start with a very generalized vision and develop increasing levels of detail as needed.”

The experience of many companies has proven that very few EA implementations work perfectly from the beginning.  There will be failures. So if we work hard to develop the “perfect” and/or “complete” EA framework, not only will we inevitably fail, but we will have lost our perspective of what’s important and it will have taken so long that our results will no longer be seen as relevant.

I have seen this last result many times in a number of the jobs I have worked.  You put in a request for a very specific change, and, by the time the responsible party actually gets to the change and gets it done, it’s no longer needed. In my current role, my  developer team focuses on smaller iterative programming changes so that, not only do we get results quicker, but we get feedback from our customers faster as well.  If we wait for 12 months before releasing a software patch, some of our customers will have forgotten that they had an issue because they came up with a workaround in the meantime.  By releasing more frequent patches, we can resolve issues faster and have more constant user feedback, which in turn helps us release a better product. Of course, too frequent can be its own problem due to constant updates and business downtime, but that’s a different issue….

I can see EA having the same challenges during a new implantation. EA becomes a buzz word at the beginning of the project with high expectations from all the stakeholders, but, by the time actual results occur, everyone has already lost their momentum. By aiming for smaller and more achievable goals, the results can quickly be tied to improvements in the business processes and the value of the EA program is rapidly recognized.

This goes back to the concept in Scott Benards’ “An Introduction to Enterprise Architecture” where he frequently used a home architecture metaphor to represent EA.  If we are planning on building an entire house from scratch, we don’t wait until the entire construction is complete before either testing out sections of the work or getting feedback from the developer/owner.  It would be a real challenge is we finished the whole house only to discover that we didn’t correctly install the plumbing…!!

#ea872 #foundations #ea