Epignosis

Image Source: FineArtBookStore

Patterns are everywhere.  We find them in nature, science, technology, business and even relationships.  The above graphic is typically called the Golden Spiral, which is a geometric representation of the Golden Ratio which, in turn, is a representation of the Fibonacci sequence [x_n = x_n–1 + x_n–2].  This mathematical pattern has been found to occur in many instance in nature.  (http://world.mathigon.org/Sequences)

Image Source: Tea Break Tog

In addition to patterns we find in nature, we create patterns as well.  If we create patterns of behavior, we typically refer to those frequently repeated actions as habits.  But we also find that we use patterns in creating items as well.  Take, for example, the craft of quilting.  Technically, quilting is really about the specific technique used to create the final product. However, over time, the craft has become associated with the different various quilt blocks that make up a single quilt.  Interestingly enough, the history of quilt making shows that, originally, quilts were formed by adding small pieces of fabric or strips to an ever-growing larger piece. As the piece grew larger, this technique proved to be very cumbersome and difficult to work with due to the final size.  Over time, quilters gradually began using the concept of quilt blocks to make the process easier.  In this way, the quilter would create smaller manageable blocks of quilts and then at the end, combine them all into a single larger piece. (http://www.quilting-in-america.com/quilt-blocks.html)

Image Source: Pinterest

Even in software programming, the concept of reusable objects is very prevalent, having starting gaining momentum back in the 1960’s and 1970’s. By creating reusable sections of code, these “libraries” of code could be shared among different programs, even among different programmers.  The code objects are not complete on their own, but are designed to fulfill a specific function that is repeatable, and by building together multiple objects, a complete program can be designed.

As we start diving deeper into the Implementation portion of the Future Architecture, the concept of Technical Patterns has emerged.  These are “repeatable, ordered sets of technical components and services that support common, repeatable requirements.” (Robertson, 2006)  Many parts of the EA implementation may have been already been created previously, so why invent the wheel again?  By reusing existing technical patterns or by creating new patterns during the implementation phase, much time and effort can be saved later in the process.  This also helps the implementation adhere to any existing EA standards as the existing technical patterns would already be in compliance with those standards. By building smaller, repeatable pieces, the implementation phase time and effort can be reduced.

#ea872 #patterns

Reference:

Robertson, B. (2006) Use Technical Patterns to Speed Architecture Benefits (G00143285). Gartner, September

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