Image Source: pymnts,com

There are many similarities between making a physical journey and the “journey” of Enterprise Architecture implementation.  Many of my previous blog posts have touched on those similarities.  This week, I want to continue building on that metaphor as we take a look at the EA Roadmap.

According to Gartner, the EA Roadmap is “a concise and commonly graphical depiction of a planned migration toward a future state.” (Weiss & Robertson, 2006)  Just like a regular road map shows the path to follow to get to your destination, the EA roadmap charts the course to navigate from the current-state to the future-state.  And similar to a regular road map, the scope of the journey dictates the level of detail of the map.  Lets consider two different examples.

Suppose I am driving from Philadelphia to New York for a meeting. The level of detail I need to know and my overall plan is determined by my purpose of the trip.  My sole intent is to  get to my destination so, in this case, I simply need a high-level overview map which gives me the most direct route available.  I need to determine my destination (future-state) and take stock of my current situation (current-state).  Do I need to fill up my gas tank?  Do I need money for tolls?

However, let’s consider a longer trip such as driving from Philadelphia to Chicago. Again, my intent and purpose dictates the details and information I will need along the way.  I know ahead of time that this is a much longer trip.  In addition to the previous necessities, I now need to consider the need for food and beverage along the way.  Will I try to drive the 12 hours all in the same day?  Will I need to stop overnight?  If I am going to stop half-way, then I need to know the details of where I am going to be stopping as well.

The EA Roadmap operates in the same manner.  We have documented our future-state in detail.  We assess our current-state as needed.  We then determine the scope of our needed roadmap and create our EA plan accordingly.  Along the way, we rely on our Guiding Principles and Standards to keep us on track.

References:

Weiss, D. & Robertson, B. (2006) Enterprise Architecture Road Maps: Closing the Gap to the Future State (G00140082). Gartner, September

#ea872 #roadmap

Image Source: BoardGameGeek

The reading material for this week concerned the process of documenting of the current-state.  As we were advised earlier in the class, the future-state (the destination) should be documented first, and any current-state documentation should be kept to the bare minimum that is necessary (Burke, Papegaaij & Guevara, 2011).  So how do we determine how much is necessary?

The key, according to Gartner, is to “identify the gaps between where you are today and where you want to be in the future, and then develop plans to bridge these gaps” (James, G. 2006). Let’s think back to the example I used in week 6 of the exploration that happened  during the Age of Discovery. Columbus had a concrete plan for his trip west to find India.  He had to make preparations for the long journey into the unknown as best as he could, including supplies, crew and navigation plans.  This is all part of implementing a plan to reach his destination (future-state).  Once he had the plan in place, though, he had to actually take stock of his existing supplies before he could embark on his journey.  Then he would need to purchase the balance of supplies he needed to reach the planned capacity.  If you needed, for instance, 20 barrels of fresh water and already had 10, you are only going to purchase 10 more.  You first evaluate what you will need, then evaluate what you already have, and then you know how to meet the remaining needs.  In the process of determining our needs to achieve our destination (gap analysis), we can ignore aspects of our current-state that have no relevance to the future-state.

The same is true for Enterprise Architecture.  Too many times, enterprise architects get caught up in the process of creating complete documentation of the current-state of the architecture. There are many aspects of the current-state that have no real relevance to the desired future-state, and time spent documenting those aspects is time wasted.  Instead, enterprise architects must prioritize the current-state documentation on only the aspects that are reflected in the future-state documentation.

Image Source: myCareerCoach

References:

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

James, G. (2006) Just Enough Current-State Architecture (G00140767). Gartner June

#ea872 #startingpoint

Image source: about.com

Throughout history, there has been a change in the significance of the flag in a time of war.  For the most part today, the flag is simply a symbol of the nation, used at government facilities. For our military troops, it acts an indicator of nationality. Previously though, in the beginning of the modern age, there was much more significance associated with the flag, or the standard, as it was commonly called.  The flag was a symbol of identity and honor. Nowadays, the only time we see anything that is similar would be the flag bearers at the Olympic Opening Ceremonies leading the group of athletes from each country. Historically, the job of standard-bearer was one of pride and dignity, even though there was much danger associated with the role as well

This tradition of carrying the standard in the middle of battle dates back to the early Roman Empire.  The Roman army was divided into regimented groups of set sizes.  The smallest was the Century which was made of up 80-100 troops.  A cohort was made up of 6 centuries, and a legion was made up of 10 cohorts, roughly 6000 troops. (Organization of the Roman Legion) The commanding officer of each century was called a centurion, and the most senior of the centurions would lead each cohort. The commanding officer of the First Cohort was the ranking officer in the legion. (Wikipedia) The First Cohort was also given the honor of carrying the standard for the legion as well as the Roman Aquila (eagle) which was a symbol of the Empire.

So what do these flags and history lessons have to do with Enterprise Architecture, you might ask?

Even though the standards were symbols of honor and pride, they had a much more practical use as well.  The standard-bearer would always be part of the front line troops, and, many times, together with the commanding officers.  The highly visible standard lifted high on the battlefield served as a rally point for all the surrounding troops.  They could follow the movement of the flag in the midst of a chaotic and noisy battlefield.  The standard gives visual directions to the rest of the troops.  If your unit got out of formation, you could always survey the battlefield, find your standard, and work your way back to its location.

In the same way, a business standard is a reference point for decision making. The standard helps us to remain on track and gives us the ability to measure if our actions are on the proper course. Standards come in many variations as well. Some standards are hard lines that are absolute. Others act more as guidelines that help nudge us in the right direction. Most importantly, standards are not meant to be hindrances to getting business done. Instead, they are established boundaries which direct us toward common goals and allow us to operate most effectively.

#ea872 #standards #rallyroundtheflag

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