Image Source: Pinterest

“Man is born free; and everywhere he is in chains.” (J. Rousseau, “The Social Contract”)

For the most part, we all hate rules.  Whether they are personal rules or business rules, the idea of having to follow rules that someone else created irritates us at some point.  Even if we understand that the rules have been set up to benefit us, there are times when our nature is to resist or challenge those rules.

Image Source: RoadTrafficSigns

How often do we see the speed limit sign and intentionally ignore it?  Yet, for the most part, we typically won’t ignore the other ones posted above. Why?  What makes us choose to ignore one and obey the others?  I think that the reason is because we treat the speed limit as a suggestion with no real consequences, while we know that the others could potentially have deadly consequences. If we choose to ignore the Do Not Enter, we could get a ticket, but we could also have a head-on collision with another car and suffer injury or even death.  Those thoughts are in our mind, and help us to obey the law.

Traffic rules and laws for the most part have been created for our benefit. As much as they can frustrate us at times, in general, they provide us with a safer environment.  A big part of the reason for this is that the rules apply to everyone.  Because we know that everyone is expected to follow the traffic rules, then we can have an expectation of how other drivers will behave.  At the same time, if we choose to follow the rules, instead of being suppressed, we gain a freedom of sorts.

“The modern man says, ‘Let us leave all these arbitrary standards and embrace unadulterated liberty.’ This is, logically rendered, ‘Let us not decide what is good, but let it be considered good not to decide it.’ “ (G.K. Chesteron, “The Heretics”)

Only by knowing and understanding the boundaries within which we can freely operate, will we be truly “free”.  This is the exact reason that there is a reduced speed limit posted for a sharp curve in the road.  By driving within the constraints that are established, we can be safe to make the journey on the road.

Within Enterprise Architecture, and in Business in general, the same philosophy applies.  Rules (Governance) are in place to help us achieve our maximum potential. Back in week 4, we talked about Guiding Principles providing a “nudge” as we navigate the path of business strategy decisions.  Governance now adds an additional layer of guidance in providing the absolute boundaries that we need to operate within.  As we travel down the road of EA Implementation and Business Strategy, our guideposts (Guiding Principles) help keep us on the right track while the traffic rules (EA Governance) help to keep us within the accepted parameters of operations.

Image Source: RoadTrafficSigns

#ea872 #governance #lotsofroadsigns

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