/Tag: Governance

How Enterprise Architects can cope with Opportunistic Failure

By |2012-03-05T12:53:50+00:00March 5th, 2012|Enterprise Architecture|

You may not think that Failure is a desired outcome, and on the surface, there are some negative connotations to failure.  It just sounds “bad” for a team to fail.  However, there are times when a manager will INTENTIONALLY fail in a goal.  Let’s look at the scenario where a manager may choose to fail, and see whether EA has a role in either preventing that failure, or facilitating it.

What is Opportunistic Failure?

Does your organization manage by objectives and scorecards?  Scorecards and metrics are frequently used management tools, especially in medium and large organizations.  In a Manage-By-Objective (MBO) organization, a senior leader is not told “how” to do something, but rather a negotiation takes places that results in the development of a measurable objective.  The term “measurable objective,” used here, is a well-defined idea.  It is specific, measurable, actionable, realistic, and time-bound (SMART).  A measurable objective is a description of the results that a senior manager is expected to achieve.  In BMM terms, the objective is the “ends” while the senior leader is expected to figure out the “means.”  In business architecture parlance, the objective describes the “what” while the senior leader is expected to figure out the “how.”

Now, in many situations, a senior leader has to rely on other groups to perform, in some way, in order for him to achieve his measurable objectives.  This is quite common.  In fact, I’d say that the vast majority of senior-level objectives require some kind of collaboration between his or her people, and the people who work in other parts of the organization (or other organizations). 

For a small percentage of those dependencies, there may be competition between the senior leader’s organization and some other group, and that is where opportunistic failure comes in.

The scenario works like this: 

Senior leader has an empowered team.  They can deliver on 30 capabilities.  Someone from outside his or her organization, perhaps an enterprise architect, points out that one of those capabilities is overlapping.  Let’s say it is the “Product Shipment Tracking” capability.  The EA instructs the senior leader to “take a dependency” on another department (logistics in this case) for that.  The senior leader disagrees in principle because he has people who do a good job of that capability, and he doesn’t want to take the dependency.  However, he cannot convince other leaders that he should continue to perform the “product shipment tracking” capability in his own team. 

So he contacts the other department (logistics) and sets up an intentionally dysfunctional relationship.  After some time, the relationship fails.  Senior leader goes to his manager and says “we tried that, and it didn’t work, so I’m going to do it my way.”  No one objects, and his team gets to keep the capability.

In effect, the senior leader felt it was in her own best interest to fight the rationale for “taking a dependency,” but instead of fighting head-on, s/he pretends to cooperate, sabotages the relationship, and then gets the desired result when the effort fails.  This is called “opportunistic failure.” 

Thoughts on Opportunistic Failure

Opportunistic failure may work in the favor of anyone, even an Enterprise Architect.  However, as an EA, I’ve most often seen it used by business leaders to insure that they are NOT going to be asked to comply with the advice of Enterprise Architecture, even when it makes sense from an organizational and/or financial standpoint. 

In addition, one of the basic assumptions of EA is that we can apply a small amount of pressure to key points of change to induce large impacts.  That assumption collapses in the face of opportunistic failure.  Organizations can be very resistant to change, and this is one of the ways in which that resistance manifests. 

Therefore, while EA could benefit from EA, I’ll primarily discuss ways to address the potential for a business leader to use operational failure to work against the best interests of the enterprise.

  1. Get senior visibility. – If a business leader is tempted to use opportunistic failure to resist good advice, get someone who is two or more levels higher than that leader to buy in to the recommended approach.  This radically reduces the possibility that the business leader will take the risk to his or her career that this kind of failure may pose.
  2. Get the underlying managers in that senior manager’s team on board, and even better, get them to agree to the specific measures of progress that demonstrate success.  This creates a kind of “organizational momentum” that even senior leaders have a difficult time resisting.
  3. Work to insure that EA maintains a good relationship with the business party that will come up short if the initiative does fail.  That way, they feel that you’ve remained on their side, and will call on you to escalate the issue if it arises.
  4. Play the game – look for things to trade off with.  If the senior manager is willing to risk opportunistic failure, you may be able to swing them over to supporting the initiative if you can trade off something else that they want… perhaps letting another, less important, concern slide for a year.  

 

Conclusion

For non-EAs reading this post: EA is not always political… but sometimes it is.  Failing to recognize the politics will make you into an ineffective EA.  On the other hand, being prepared for the politics will not make you effective either… it will just remove an obstacle to effectiveness. 

Governance in an Organic Enterprise

By |2011-09-28T04:32:12+00:00September 28th, 2011|Enterprise Architecture|

I spent a few minutes this evening reading through Tom Graves’ fascinating post Management as ‘just another service’ and it got me thinking of Governance in the organic enterprise.

As Tom describes, there are two paradigms of management at play: organization as machine, and organization as living organism.  Tom is of the opinion that most organizations think that they are of the first type, while they actually behave like the second type.  While I cannot quantify his assertion, I have noticed that my own organization behaves more like an “organization as living organism.”

So, this evening, as I contemplate the notion of enterprise governance, I consider the reality of improving governance in an organization that behaves more as an organism than as a structured automaton.  In order to share my thoughts, I want to establish some basic terms to make sure we are all on the same page.

First off: Governance is a system of distributing decision rights to specific individuals or groups so that (a) desirable behavior is encouraged, (b) undesirable behavior is discouraged, and (c) business rules are aligned with enterprise principles and legislative constraints.  Governance can be a simple as having the project sponsor review the project plan, and as complicated as having the United States Supreme Court review the specific clauses of President Obama’s healthcare reform law, before the administration compels the various states to implement it.

There are many things that can be governed:  the scope of projects, the expected architectural outcomes, the assignment and activity of individuals, the assignment of responsibilities to teams and systems, the correct handling and security of information, and the measurable performance of processes, to name a few. 

In addition, there are many different levels at which governance occurs.  Governance can occur at the personal level (I choose to do the right thing).  It can also occur at any “level” where a group of people with specific decision rights have a stake in the governable elements of an activity.  To whit:

  • A team may want to govern the efforts of its members. 
  • A business sponsor may want to govern the activities of a project team that is spending his or her money. 
  • A cross-business virtual team (v-team) may want to insure that dependencies between teams are carefully managed in order to insure the delivery of value. 
  • A senior business executive may want to govern the level of acceptable risk in a portfolio of projects to insure that there is a good balance between innovation and incremental improvement. 
  • A senior leadership team may want to insure that leaders have clear ownership and accountability (no gaps or overlaps) so that strategic changes can be implemented in cross-functional processes.

This may lead you to conclude that governance can be performed as part of a hierarchical escalation process, but that is not a foregone conclusion, as you will see below.

When designing a system of governance in an organic enterprise, we need to make sure that the “solution” matches both the “problem” and the organizational “network of influence” (instead of hierarchy) that the enterprise uses to make decisions and resolve disputes. 

So let’s break down the problem a little.  What is the array of problems that organizational governance (of which IT governance is a subset) is supposed to solve?  Here are some elements of that array:

  • Senior leaders are consulted when the cost of day to day operations overwhelms the organization’s ability to behave strategically
  • Business Managers are consulted when investments by one business manager can interfere with the efforts of another
  • Process owners are consulted as a process is being changed, leveraging organizational knowledge and experience
  • Information facet owners are consulted as requirements emerge that impact master data management and data quality
  • Platform owners are consulted for the improvement of business capabilities supported by enterprise platforms
  • Architectural owners are consulted as system designs are considered for inclusion in the enterprise IT ecosystem
  • Organizational standards are followed in order to minimize the cost of ownership of process, system, information, and infrastructure investments

 

The key thing to note from this list is that different “governors” are interested in governing different things.  There is no simple “chain” of escalation.  Rather, it is a network.  This is one effect of organic governance.  Another is that the number of levels of governance, for any one issue, should be fairly short.  You deal with things at an individual level, at a project level, and then, fairly quickly, at the level of a “governance body” designed specifically to resolve that particular type of issue for a business and then the enterprise.  Lastly, there is a senior management body that can settle all remaining disputes. 

Unfortunately, when considering this kind of problem, the metaphor of “enterprise as organism” begins to fail.  Actors in an enterprise do not behave like cells in an organism, nor do business units within an enterprise behave like organs.  Cells are regulated by internal instructions, hard-coded in chemical DNA sequences, and respond to fairly simple stimuli with pre-programmed responses.  Actors and business units do not. 

Organizations do not have consistent and uniform instructions (like DNA) that guide each person and business unit.  Governance is needed because of the variation of human beings and their desire to continuously look after their own interests.  Quickly we can see that the “organism” metaphor is shaky at best.  In small units, the metaphor of a sports team is a better metaphor, and at the larger end, the metaphor of a city is more appropriate.

I work in a fairly large company, so the metaphor of a city is better for me to consider.  After all, I’ve lived in cities all my life.  So in a city, how many times have I behaved in a beneficial way?  I’d like to believe that I do that every single day, in a hundred small ways.  How many times have I interacted with the police?  Less than the fingers on one hand.  Well… that’s interesting.  That simple observation alone makes one thing starkly clear: the police do not govern my city life.

I believe that the most important governance element of city life is the system of property laws, commercial practices, licensing laws, and simple rules of civil behavior that allow the city to be a productive and useful environment for individual people.  Governance itself is a tiny fraction of the overall efforts of the population of a city, and it is normal to live your life for years without involving a police officer, filing a law suit, or walking into a court.  That said, courts and lawyers and legislative bodies are essential overhead.  From an economic standpoint, governance is overhead and waste.  People who govern contribute nothing.  But from a social standpoint, the system of governance is critical to the success of the “organically” managed city. 

Which leads me to a rather startling conclusion: In order for a large organization (of say 100,000 employees) to successfully becoming a mega organization (of say 1,000,000 employees), they must develop a simple and fair system of property laws, commercial practices, licensing laws, and rules of civil behavior, and a simple adjudication system to address conflicts.  Hierarchy do
es not work as a model of governance in an organic enterprise.

The Rule of EA Governance

By |2011-07-21T17:52:23+00:00July 21st, 2011|Enterprise Architecture|

There is a clear distinction between Enterprise Architecture, as described by the architect, and Enterprise Architecture as implemented by the enterprise.  I would like to posit the following as a fundamental principle that describes the difference:

All Enterprise Architecture will be implemented according to the structure of ownership and governance that exists in the enterprise. 

This is essentially an update to Conway’s Law, but Conway was focusing mostly on application development.  Conway’s law, dating from 1968, is:

…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. “

Many of the factors that drove Marvin Conway to describe software design are also at play in enterprise architecture.  Organizations want to use the teams that they have, so they will design software in such a way that it can be coded by those teams, regardless of whether that is the best way to design or deliver that system.  For example, if your company has a team of people who manage the CRM system, and a team that manages Web front-ends, then any business scenario that involves web front-ends on a CRM system will have exactly two modules.  One will be written by the Web-front end team and the other by the CRM team.

In Enterprise Architecture, the effect plays out quite differently.  EA often creates recommendations to consolidate systems, reduce overlaps, fill gaps, and optimize spending.  Since EA doesn’t design software, Conway’s law doesn’t apply. 

So how does the Rule of Governance work you ask?  If you have two business customers who both want a CRM solution, and you have one governance body, you will end up with one CRM system.  If you have two governance bodies, you will end up with two CRM systems.  If you have four business units who want CRM, and you have three governance bodies, you will end up with three CRM systems.

This rule plays out repeatedly.  I’ve never seen it fail. 

The failure to recognize “The Rule of EA Governance” is one of the causes for the failure of an EA program. 

Enterprise Architects are an optimistic bunch.  We honestly believe that we can influence the course of our businesses (evidence: we work as Enterprise Architects!).  We use modeling techniques and engineering principles, and produce nice drawings and great designs.  The business doesn’t care about nice drawings and great designs.  They care about “stuff they own” and “stuff they don’t own.” 

If you want to change the way the business works, especially with respect to shared processes, capabilities or technologies, an EA MUST create a mechanism for the shared “thing” to be owned by only one person.  As soon as only one person owns it, and has authority over it, it will exist only once.  If two people own it, it is a matter of time before they go their separate ways.  Of course, making sure that the RIGHT person owns it, that’s an altogether different problem.

So if you want to know if your Enterprise Architecture can be implemented, count the “things” in it.  Then count the number of those things with exactly one owner (and clear governance).  Those are the things that will be implemented just the way you describe it.  Everything else is a free for all.

Video Podcast: How Microsoft Does Enterprise Architecture

By |2011-06-23T10:36:23+00:00June 23rd, 2011|Enterprise Architecture|

It is amazing how often I need to share the very basic concept of Enterprise Architecture with my peers, customers, stakeholders, and associates.  Microsoft’s customers often ask about Enterprise Architecture, and when our customers come to visit us in the Microsoft Executive Briefing Center, they are more frequently bringing their Enterprise Architects along for the conversation.  To help clarify our view of EA, I teamed up with the Microsoft Showcase team and Microsoft Studios to produce a podcast describing Enterprise Architecture. 

The podcast is located on the Microsoft IT Showcase site here.

I thought about including a transcript, but I don’t have one.  I mostly spoke from an outline.  If you have questions or comments on the video, please don’t hesitate to contact me and we can collaborate. 

Segment Architecture in a Commercial Setting

By |2011-04-25T01:37:00+00:00April 25th, 2011|Enterprise Architecture|

The notion of an Enterprise Architect in a Segment (aka “Segment Architect”) has been fairly well described in for the Federal Enterprise Architecture Framework.  (FSAM reference).  It is not always well understood, and there are a small number of blog posts that disparage the concept.  That said, in a federal context, the politics of enterprise architecture doesn’t seem to get played out across the blogosphere. 

I am getting moderate traction at implementing the notion of segment architecture in a commercial setting, and I’d like to share my experiences with the community.  This post is one of what will likely become a series of posts on the trials and tribulations of implementing commercial segment architecture.

Preface: FSAM without the bureaucracy

First, a caveat and caution to those folks who are intimately familiar with the implementation of the Federal Government version: while I took a great deal of inspiration from FSAM, I cannot pretend that I have made any real effort to implement the FSAM in my organization.  As an outsider to Federal IT governance, I am looking through a very narrow lens.  The OMB is the overseer of overseers.  They rely on reports submitted by the agencies themselves.  Each agency is a large organization with billions of dollars of funding. In order to support the multiple tiers of oversight demanded by Congress, huge amounts of information must be put into standardized reports and fed upstream for oversight.  This emphasis on standardization and documentation is simply overkill in a commercial setting, where governance is a matter of judgment, and not a campaign pledge or a debate on CSPAN. 

I appreciate the difficulty of the OMB’s job.  I’m glad I don’t have to do it.  In that vein, I started my implementation of segment architecture by tossing out the extraordinary reliance on reports.  I stuck to the goals and concepts of segment architecture.  And that’s where I’d like to start in this post: what problem does segment architecture solve?

The ivory tower problem

The first step in understanding a problem from an architectural standpoint is to explain the problem as a set of interacting responsibilities.  For folks of the BPM bent, this can mean looking at a series of high level business processes.  For folks of a more architectural nature, this is often thought of as a set of interacting capabilities, each of which produces, consumes, or manages information as part of a larger system dedicated to a goal.  These architectural models are extremely useful, because they help to create a mechanism for understanding the problem space and for creating clear solutions.

However, reference models and taxonomies are not solutions.  No one can implement a reference model.  These “thinking tools” are inputs for specially trained individuals, and cannot be used by business people.   Reference models are architecture, but they are architecture for architects.  They are the patterns that architects use, not the blueprints that builders use.

image

On the other side, there are problem solvers.  Traditionally, in both business and government, an empowered individual will decide that “my organization will go after this goal” and they will direct their team to get to work.  The team may have to modify their existing processes or change their existing systems, and the goal is quickly broken down into a gap analysis, a proposed solution, and an implementation program.  The program will trigger and manage a series of projects and the results will be measured and reported. 

These activities are well understood and problem solvers have been promoted into management on the basis of doing these activities well.  As a result, there is great understanding for them, and support of them.  This culture does not care about reference models, taxonomies, or assessments.  This culture is well populated, and is seen as either the solution or the problem (depending on whether they are successful or not).  This culture of problem solving often outnumbers the architects (100 to 1) and they are slow to change. 

To the problem solvers, enterprise architects live in an ivory tower. They create models that are correct, but useless.  They do work that is visible, yet not necessary.  They spend time and money without solving any real problems.  To the problem solvers, a reference model is pretty useless.  A reference model plus $5 will get you a cup of coffee. 

Building bridges from both directions

In order for the problem solvers to gain any value at all from the reference models and taxonomies, those artifacts need to be correct and relevant.  Without specific information, they can be pretty, but not pretty useful.  From the solution side, enterprise architects need to gain understanding, relevance, and a tie to the work that actually must be done, the dates it must be delivered in, and the costs that play out across the infrastructure.

For the enterprise architects to have an impact on the problem solvers, their models must also be understood, and there has to be a set of key individuals who use those reference models to get the problem solving moving forward.  There has to be an understanding of how to use the information collected, and how to solve specific enterprise problems.  The problems that an EA is trying to solve are different problems than the ones the business is focused on.  The EA problems are around total cost of ownership, not solution development.  They are around consistency, simplicity, and reliability.  They are not normally focused on specific features, specific constraints, or specific interfaces.

A bridge must be built.  The realization that led to segment architecture is that this bridge cannot be done with training or artifacts or databases… the bridge is constructed of people.  Those people are Segment Architects.

Enterprise, Segment, and Solution Architects

In the problem solving space, you need solution architects.  These are the folks who will build the actual solutions that the business needs from the parts available (existing systems, databases, processes, hosting providers, authorization systems, etc.).  In the enterprise space, you need the enterprise architects.  These are the folks who evolve the future state for the enterprise’s processes, information, roles, and tools.  In the middle, you need the segment architects.  These are the folks who work with the business during the goals, gaps, and solution stage to insure that they enterprise needs and solution components come together. 

The segment architect is responsible for the following:

  • Developing a deep relationship with the business and developing a deep understanding of the problems that need to be solved.
  • Understanding the reference models and providing the needed information to build, evolve, improve, and implement them in the segments.
  • Assessing the state of the processes, information, roles, and systems that are involved in a particular business area to inform the solution efforts
  • Developing the initial “conceptual solutions” needed in order for the programs and projects to get under way, and for the solution architects to have a reasonable and achievable scope to operate within.

 

reaching_chasm

The distinct role of Segment Architect

For a while, I’ve had a challenge that is not simple to explain: how is a Segment Architect different from the other roles.  Not simple.  Here’s my attempt for tonight.

First off, let me say this: a Segment Architect is an Enterprise Architect.  He or She is assigned to work within a segment, but could be reasonably assigned to another segment (and in fact, should be periodically reassigned in order to retain their independence).  The segment architect is accountable for all of the responsibilities of an enterprise architect.  He or she must “own” enterprise requirements and insure that they are implemented in line-of-business solutions to the best of his or her ability.  As an EA, they care about where information is created, where it is mastered, and where it is manipulated.  They care about which business units perform specific business processes at a high level, and which governance mechanisms will be used to measure results. 

That said, in the early planning stages, the Segment Architect fills in the (not-yet-funded) role of a solution architect.  He or she will consider all of the requirements, well before they are reasonably understood, using the reference models and taxonomies as analysis tools.  They will develop a conceptual solution that allows the organization to understand what teams will be involved, what systems will be targeted, and what information should be mastered.  Without the segment architect assigned, the business units will perform this architectural activity without any architects in the room, and the result is quite dangerous.  That said, the solution concept developed by the segment architect is a pencil sketch compared to the actual solution that will go live.  It is directionally correct, but the real solution may take on a very different character.

The segment architect does not get the privilege or the honor of actually delivering the solution.  That honor, and that responsibility, falls to the solution architect who will be held accountable for meeting enterprise requirements as well as solving specific business problems.  The solution architect is assigned to the actual project, and has to deliver on it.  The EA does not.

Tell me what you think

I hope that this article provides some of the basics of segment architecture for the EA community, and opens up a channel of dialog about this important and emerging role within the Enterprise Architecture profession.  I am open to questions and concerns, which I may answer in subsequent blog posts.  Please feel free to share your ideas.

One bit of credit that I’d like to give.  Finding an image of a chasm that business people can cross is not easy.  The images if a chasm that I used in this blog post originated from an April 2004 article on the IBM web site called “Bridging the Chasm between Strategy and Execution” by Sydney Fuchs.  The article is quite good and I recommend it, but the context is not quite the same as I used in the image here.  I did not ask for permission before absconding the image, modifying it, and repurposing it.  I hope that Mr. Fuchs will forgive the intrusion.

The responsibility of architecture is to create an architecture of responsibility

By |2011-03-09T01:47:43+00:00March 9th, 2011|Enterprise Architecture|

I cannot take credit for that aphorism… credit goes to Jan Van Til.  He coined the term after reading Tom Graves’ excellent post on the architecture of responsibility.  Tom’s post details the philosophical challenges of a responsibility-based economy.  However, I’d like to get a little more tactical in the Enterprise Architecture space, and discuss more of the “intra-company” and “intra-solution” aspects of “The Architecture of Responsibility.” 

One of the key accountabilities of Enterprise Architecture is to provide a mechanism to govern the development of corporate business capabilities. In other words, we want to make sure that specific capabilities are developed, in a principled manner, prioritized on the strategy of the business. 

When making that governance mechanism work, I find myself routinely dealing with the same issues that Tom outlines.  We do not select a system because of it’s technical prowess or smart operators.  We look at the capabilities needed by the business, and assign responsibility to the business team that is willing, able, positioned, and passionate about taking on the responsibility for that capability: shepherding and improving it, operating it effectively, remaining agile, while keeping a keen eye on both risk management and cost efficiencies. 

I’d like to point out a key aspect of governance.  It is not about assigning responsibility to a system or system component.  No one can govern the assignment of a responsibility to a system.  What can be governed, effectively, is the assignment of responsibility to a business unit.  That business unit can own information and the systems that manage it.  You need people to make governance work… not just to govern, but to be vested in the success of the “optimal architecture.”

Hence, the architecture of responsibility is the mapping of capabilities and business processes to people.  Sometimes that means consolidation to common processes, but not always.  That depends on the operating model of the business.  But always it is a problem if a particular capability within a business model has no owner.  Identifying the businesses within an enterprise, the capabilities within the business, and the owners of the capabilities… that is a key deliverable of Enterprise Architecture.

One that is not often discussed… but in the end, extraordinarily important.

It’s not about cost savings… it’s about value

By |2011-03-01T10:57:59+00:00March 1st, 2011|Enterprise Architecture|

The word ‘value’ has too many meanings and sometimes it masks a real problem. 

I had a conversation with a very smart customer recently, where their IT division is going through a transformation to help their business compete.  I asked if their transformation has the purpose of making IT cost less or increase business agility.  Their answer: It’s less about cost and more about value.

To me, an answer like that is vague.  It sounds good, but what kind of value is IT supposed to deliver? 

And that is the core question we should always ask of the business.  We shouldn’t be asking IT to deliver “generic” value.  We should be asking IT to deliver specific value, to make changes that will meet specific business goals.  And that requires that the business describe their strategies in terms of specific business goals.

Getting alignment to “generic value” is like having a teenager tell you that their room is clean.  Too many definitions of the word.

Alignment without specificity is not possible.

Enterprise Architecture and the Lessons of History

By |2010-12-24T17:24:05+00:00December 24th, 2010|Enterprise Architecture|

I am an Enterprise Architect.  It is my job to look at things the way they are, and envision the things that should be.  It is my role to describe specific actions that specific people can take to change things (systems, processes, corporate structures, etc.) to lead an enterprise towards a better place.  The role is fascinating.

Yet I am troubled.  The role of Enterprise Architect is troublesome to a student of history and society.  Because in the history of humankind, there have been many people who have performed a similar role, and many of their actions led to terrible consequences.  How can I follow in their footsteps?  How can I not?

At this point, perhaps you are asking: what on Earth is Nick talking about?  What terrible consequences have Enterprise Architects wrought? 

The answer is elusive and yet painfully obvious: our role includes great promise but also great potential for harm.  We can focus innovation, or we can stifle it.  In the stifling of innovation, we can cause great harm in a single bad decision.  A single innovation may be the difference between a competitive idea and a market-creating idea.  In even starker terms, a single innovation may illustrate the line between success and failure, and between profit and loss. 

Here is the pattern that is so troublesome to me:

  1. Understand a great deal about the system
  2. Envision a future in which the system behaves “better” than it does today
  3. Create rules to guide the behavior of specific actors within the system
  4. Review the behavior of specific actors to find those who are not following the rules
  5. Recommend to a “higher authority” that a law-breaker should be prevented from proceeding on the basis of their “law breaking.”

Most Enterprise Architects will see, in this pattern, the notions of Future State Architecture, Architectural Principles, and Architectural Review.  These concepts are widely shared within our community and many good white-papers have been written to provide guidance, from one EA team to another, on how to “force” a wayward IT project to “follow the architectural principles that the enterprise agrees will lead to a better future.”

Take care, fellow EA, to learn from the lessons of history.  Consider these examples, and bear them with humility. 

Example 1: The Crucifixion of Christ

Consider the system: human society.  The challenge: how do we “encourage” individual people to behave in a manner that, taken as a whole, produces the greatest individual liberty?  What does the “better” society look like, and what rules should we follow to get there?  Moses took up that challenge and those that followed created a body of Law that not only led the Jewish people, but even today forms the basis for three great world religions (Judaism, Christianity, and Islam, in order of emergence).  With the body of law, we have achieved steps 1, 2, and 3 above. 

With the administration of the law, we introduce a legal concept that prevailed during the time of Christ: the Sanhedrin.  This council of scholars were charged with understanding the complex rules written in the Law, and reviewing the behavior of individual people to see if they had violated “the rules.”  They made their recommendations to the Roman governor of Judea.  In their review of Jesus, they found his behavior to be in violation of the rules.  His vision did not match their own.  The results are both tragic and rather well known, so I don’t need to go into the details of the crucifixion here.

This example is particularly poignant to me because I am Jewish.  If I had lived at the time of Jesus, would I have recognized him as an innovator?  Or would I have seen him as the Sanhedrin saw him, as a heretic?  Would I have seen him as a person attempting to create a new religion that today leads a billion people towards moral behavior, or a provocateur that threatened to lead people AWAY from the “future state architecture” that the trusted council had envisioned?

Example 2: The Trial of Galileo

Flash forward to 1633.  Perhaps after a millennium and a half, humanity would have learned… right?  Au contraire. 

The religion founded on the prior example, Christianity, is fully in charge in Europe.  However, the Renaissance is in full swing, and the authority of the Roman Catholic Church is under attack.  In this age, the power of Catholic Church reached into the daily lives of kings and peasants alike.  But here comes Galileo to suggest that Copernicus was right: that the Earth was not the center of the universe.  Someone, quick, tell the Pope: Galileo is not following the standards!  Galileo must be told to “Stop what you are doing… you are jeopardizing our vision of the future.”  After all, how will people get to heaven if they doubt the church that is supposed to get them there?

Galileo is brought up on charges, convicted, and imprisoned for the rest of his life.  His crime: innovation.  The men who “reviewed” his work and made “recommendations” to the Pope were looking to see if he was “breaking the rules.”  If I had been part of the Pope’s inner circle, would I have been ready to make an exception in my sacred rules for the innovative ideas of this great man?  Would you? 

Counter-Example: The Publication of Darwin’s “On the Origin of Species”

Jump with me one more time, to 1838.  Charles Darwin, upon visiting the Galapagos Islands aboard the HMS Beagle, discovers unique species that don’t exist anywhere else.  This voyage and his now-famous observations form the seeds of his theory of Natural Selection.  Darwin was a fairly devout man, having studied to be a pastor himself.  His wife, Emma, is even more Devout, and is very worried about his theories.  She states in one of her letters that she fears the possibility of having eternal life in heaven if Charles is not there to share it with her.  What kind of future can you aspire to when the love of your life questions the people who promote it. 

It took 20 years for Darwin to publish his book, partly because he needed to come to terms with the innovation he had stumbled upon, and partly, some historians suggest, because he needed to come to terms with his concern for Emma and her beliefs.  Yet, publish he did.  He performed the same act that Galileo did: to innovate.  In many ways, it was the same act that the Illiterate Jesus performed nearly two-thousand years earlier: to challenge the status quo and create a vision of the future that made sense, yet did not follow (or even compelled one to break) the rules of behavior that prevailed at that time. 

But did the British police come to arrest Darwin?  No.  To the immense credit of his time, and the overall understanding of the Age of Enlightenment, Darwin lived out his life as a free, and freely thinking, man.  Why?  Because there was a process, and a self-governing body of thought leaders, who cared about encouraging innovative thoughts and ideas.  In Darwin’s case, this was The Royal Society of London for Improving Natural Knowledge.  His innovations were so widely celebrated that, by the time of his death, he was honored with a State funeral, one of only five non-royals to be so honored in entire eighteenth century.  He is entombed in Westminster Abbey near the remains of Sir Isaac Newton. 

There is an interesting distinction to make about Mr. Darwin here:  He saw that the evidence in nature didn’t fit some of the underlying assumptions of the Church of England (a
nd most other branches of Christianity), but he did not directly challenge the religion itself.  He did not describe alternate rules for people to follow, or create a new religion.  Darwin observed, drew conclusions based on evidence, and published what he believed were valid theories. 

He has since been proven to be right in more ways than he could have ever predicted.  The entire field of modern Biology rests on the ample observation of evolution.  His ideas “went viral” long before those words were coined.  The concept of “survival of the fittest” has been used (or misused) in nearly every other field of human endeavor. 

What lesson can EA learn?

This small sample of events cannot create a useful of theory of human behavior.  One would need thousands of examples, not just three, to create a theory of leadership, incentive and innovation that applies.  However, there are lessons that can be drawn empirically. 

A) If you create “rules,” expect that three kinds of people will break them: Fools, Scofflaws, and Innovators.  For the first, apply education.  For the second, apply incentives.  For the third… be willing to change the rules. 

B) Innovation may challenge your idea of both the goal, and the method to get there.  In the execution of the EA program, be careful not to execute the innovator.  To avoid this possibility, create a process for encouraging innovation, not just providing an exception for it.  Have a body of people who are motivated to innovate and take their council seriously.  Exceptions are unnecessary if innovation is recognized.

C) No matter how hard you work to create a vision for the future, and to create “beautiful rules” to lead people there, perfection will elude you.  Do not strive for perfect vision or perfect rules.  Strive instead to create a system where the rules, and the vision, change with the times.  Your business will change.  You will change.  Technology will change.  Stakeholders will change.  Competition will change.  Opportunities will change.  A static vision will do more harm than good.

So where does your EA program sit?  Do you describe the future and then set up rules to help people to get there?  Do you have a program in place for recognizing innovation, rewarding it, and encouraging it, especially when that innovation may challenge your future state architecture? 

Which example will you embody?

Enterprise Architects Are The Gears, Not The Grease

By |2010-11-16T13:08:55+00:00November 16th, 2010|Enterprise Architecture|

I’ve often heard “soft” metaphors used when discussing Enterprise Architects.  Some compare EA to the grease in a machine… necessary for the machine to run but we don’t provide the energy for progress so much as we reduce the friction.  Others use a “sticky” metaphor, saying that EA is the glue that connects strategy to execution.  Those metaphors are flawed because, in each of them, I can easily imagine a system where there is no grease or glue and the system works just fine.

I am involved in an effort to clearly define the role of an Enterprise Architect in my particular space.  The way that I’m working on this clarification, I cannot say that EA is something mushy.  EA is part of the machine itself.  To use the “engine” metaphor, an Enterprise Architect is a gear, not grease.  We work at the same speed as the engine, churning through data, decisions, and governance at the rate demanded by the business. 

I do understand that small organizations may not need an EA.  That is because the problems addressed by an EA are not so easily buried under politics and personality in a small organization.  The CEO can see them and can address them.  In larger organizations, you get shared services, competing priorities, and, in most cases, political games designed to swing decisions with partial data or one-sided decision criteria.  That is where EA really shines. 

In these environments, EA is not a ‘soft’ role. To be an effective EA, you have to know when to stand your ground and defend the requirements of the enterprise.   You can force conversations to be held that wouldn’t otherwise occur, and decisions to be made that some would rather avoid making, using data that is sometimes difficult to collect in a fair and impartial manner.  That is not a “grease the wheels” function.

Can Federal EA ever include the full scope of Enterprise Architecture?

By |2010-10-02T11:20:25+00:00October 2nd, 2010|Enterprise Architecture|

Adrian Grigoriu recently posted about the failure of EA frameworks to address real enterprise architecture, due to their focus on IT and lack of focus on business.  He is right, of course, in pointing out that TOGAF does not cover Enterprise Architecture fully and that Zachman is so poor that it fails to offer any real help in solving actual business problems.

One thing that occurs to me, today, is that the Federal Enterprise Architecture effort has some advantages on commercial EA, and some disadvantages… key changes that I believe will fundamentally divide government EA from commercial EA.

Advantages that Federal EA has

First off, Federal EA programs do not need to spend vast amounts of their resources justifying their existence.  The nature of legislation is such that a policy can be written in cement and that the policy can create the rationale for Enterprise Architecture.  We’ve seen this with the interpretation of federal legislation to build out support for EA programs.  That is a huge advantage.

Disadvantages that Federal EA has

Two disadvantages that will drive Federal EA’s evolution along different lines than commercial EA —

  1. Without the need to continually justify the existence of EA, government programs don’t have the evolutionary pressure needed to FOCUS on the activities that provide the most possible value to their organizations.  They can spend a lot of time on unnecessary activities.  They don’t have to, and well disciplined programs won’t.  But they can. 
     
  2. Federal EA will always focus on about half of the value of EA.  I view EA as being accountable for influencing and guiding the investments of an organization to improve their ability to execute on their mission.  Unfortunately, the guiding part, in a governmental system, usually happens in either the legislative process or in the policy-development (political) process.  Neither of these processes are flexible.  Neither are within the scope of Enterprise Architecture in the Federal mindset.

 

The lack of influence on funding is a key wedge between commercial and governmental EA.

Governmental EA will only ever be able to work at the micro-financing level, deciding how investments should divide up between program dollars and shared services, or clarifying the lines of alignment within a funded program.  But Governmental EA will not be able to stretch the full width of EA unless and until it includes the ability to cancel a stupid-yet-legislative-funded program, or move money to an area that the government needs, in order to meet its mission, yet the legislature won’t cover it.

What this means for the evolution of frameworks

Frameworks evolve to solve the problems that their contributors must cope with.  The Federal EA frameworks will evolve to focus on the “solution and information architecture” aspects of EA because they have no control over the formation of funding policy, only on the execution of it.  Commercial EA frameworks will be able to focus on both funding and execution, and as such, will cover a broader scope with broader reach, but will spend a much greater focus on justifying the existence of EA.