About EAdirections

How do we work with clients?

We talk.  A lot.  Every week on a scheduled basis via telephone or computer connections.  We can talk to you one-on-one, participate in your team meetings, or a combination of both.  We are very flexible.  Consider us as a partner who you can trust and who you can share your thoughts, ideas, challenges and frustrations.

We look at your work.  We’ll critique it and provide suggestions.  We’ll help you get started when you are not sure how to begin.

We will visit you on site, meeting with you, your team, and your managers and leaders.  We will conduct seminars, working sessions, facilitate, review, assess, and drive you forward.

We will make you and your team better at what you need to do.

What makes us better?

EAdirections is not a traditional consulting firm.  We are mentors.  Our goal is to help you, your team, and your organization improve and function to your maximum potential.

We are a focused team.  We are not there to identify and sell additional consulting, products or outsourcing engagements.  Our only  agenda is your success.  It is personal, and personalized.

We are unbiased.  We recognize that success comes in many flavors, and the tools and techniques chosen must be appropriate for your skills, resources, maturity, and goals.  We only care about advising you on what will work for you.  That is almost always a hybrid approach drawn from many sources.  We have the experience to interpret the needs of your organization and guide you down the correct path.

On Enterprise Architecture

What EA Metrics should we collect and report?

Choosing appropriate metrics to measure EA is challenging.  We find that most practitioners, and their management, want to see “absolute” metrics, a measure yielding some sort of generally accepted min/max in the form of a quantity or percentage (e.g. 70% of all projects are reviewed).

Instead, we believe metrics are used primarily to tune an EA program.  Metrics are relative to some planned target level, and those targets change as the program grows, matures, ages, is accepted by the community, etc.  In other words, as it evolves, the types of metrics that are tracked and their targets evolve.  Looking forward 6 months, for example, the EA leadership might be trying to establish an EA exception process as part of a stage gate in the development methodology.  Early in EA adoption we might see a high percentage of exception requests because the target EA is poorly understood or incomplete.  We may establish a goal to reduce exception requests through peer reviews, formal EA reviews, and education.  Once the number hits its target floor we set a new goal to not let the percentage rise.  If it does it might be an indication that we need to do an EA refresh or provide more project coaching.

In general, EA programs are measured across 3 general categories:

  1. EA Process Performance – internal measures of EA process activities
  2. Organizational Coverage – interaction of the EA process and content with people outside of the EA function
  3. Component Content Utility – the “usefulness” of the EA deliverables the team creates (by influencing project and infrastructure success and evolution)


Where should the EA Team report?

For an organization practicing IT-EA (IT Architecture, not True-EA) the ideal reporting location is directly to the CIO as part of the Office of the CIO. In that structure, the EA function has the widest view of all of the activities of IT and is not narrowly associated with any development or operational group. Additionally, the EA Team has the visibility and is a peer with all of those same managers.  Finally they can be considered of equal importance and integrated with the portfolio management, strategy and governance functions.

If the organization is practicing True-EA, we’d recommend the equivalent position within the Office of the CEO/COO.

If neither of these reporting structures are possible, others can be made to work via a series of compromises and approximations.  Drop us a note and we’ll be happy to set up a time to discuss your unique circumstances.

How many people should be on an EA Team?

There are many ways to instantiate an EA Team: virtual approaches, centralized teams, with and without solutions architects, etc. Regardless of the real-world constraints, the range of possible structures does not change the main objective of the team, the roles they play, and the work that must get done.

Since there are so many variations, we recommend that organizations think about the question primarily in the context of that work. There should be a role leading and/or managing the EA function, another role stewarding the repository of deliverables,  another role with strengths in communications (upward, across, and down the organization), and a role able to set up and steward the various governance processes. Additional roles should include a matrix of discrete and overlapping perspectives representing major areas important to the organization. We have seen teams organize this matrix across the various emphasis areas of EA (business, information, technology domains, solutions), across business/organization models (portfolio architects), and other hybrid models. Understand that due to resource constraints, some people may perform multiple roles, and some roles may be distributed across various reporting entities.

As a starting point for analysis, though, we recommend that medium to large organizations strive to create a 6 to 7 member core team, excluding a separate pool of solution architects of sufficient size to guide/coach individual projects. Depending on the organization’s culture, maturity, and available skills, the solution architect pool can report directly to the leader of the EA function or be distributed with dotted-lines back to the EA function.

As we say, there are many variations and it is possible to achieve a working EA function via trade-offs, compromises and approximations. Drop us a note and we’ll be happy  to set up a time to discuss your unique circumstances.

Is there really a need for an EA Charter?

The need for an EA charter is debated somewhat due to either the perceived nature of the charter document as a tactical project document or the amount of time that is required to do more than a cursory job of creating an organizational document.

Our experience has been that not only is there value in the document, but also in the effort to create the document.  The document itself helps to provide common, agreed-upon language for clarifying a vastly misunderstood term, Enterprise Architecture, within a given enterprise’s context.  The effort is valuable for two reasons.  One, EA team dynamics lean towards the dysfunctional in many cases, and the effort to collaborate on the goals, objectives and scope of EA provides a forum to vastly improve team dynamics.  Two, by taking the effort through a broader collaborative and communicative process, including formal ratification, the acceptance of EA as a legitimate and valuable practice increases significantly.

Should the EA Team also be the EA Police?

In a word, no. There are always exceptions, of course, but it is in the best interests of the organization, and of the EA Team, that the EA Team be free to make objective future state recommendations in the context of a longer-term horizon.  The organization’s leadership team should then approve those recommendations through an EA Approval Process, making them official.  The EA Team should then coach/guide projects in the correct direction, and also may help evaluate exceptions/variance requests as they occur.  Their opinion of the implications of the exception should be communicated back to the leadership team (the same team that approved the standard future state direction) as part of the official EA Assurance/Variance Process.   In both of these processes, authority must reside in the only place that truly has authority, the executive leadership decision-making body, and not the EA Team.

Yes, there are cases where it must work differently.  Contact us if you’d like to discuss your circumstances to determine the right approach for you and your organization.


What is “True-EA”?

True Enterprise Architecture (True-EA) is quite simply architecting the enterprise.  The overwhelming majority of EA efforts that we have come in contact with over the last two decades have, in fact, been IT Enterprise Architecture (IT-EA) efforts.  They have been led and operated by IT professionals working within the CIO/CTO’s organization, with a focus on IT outcomes within the domains of technology infrastructure, automated information systems, and data. True-EA manifests itself as the full context of the enterprise, planned in a holistic and comprehensive fashion, with separate ownership of the business (operations and information) domains and the IT (information technology infrastructure, application, and data) domains.  A relationship, usually formalized with a jointly represented central committee exists between the two separate but compatible efforts.  The union of the Business Architecture Domains with the IT Architecture Domains is True-EA.

Do organizations really practice “True-EA”?

During the past couple years, we have begun working with clients where the efforts of IT-centric business and information architecture efforts have been sponsored and eventually taken over by representatives of senior leadership outside of the IT organization.  While still a minority of the companies we deal with, it is a positive trend, driven by the need to transform the enterprise significantly.  This is not representative of EA efforts that are tactically focused.

Over the past few years, we have begun to see more and more enterprises investing in Enterprise Business Architecture (EBA) and, to a lesser extent, Enterprise Information Architecture (EIA).  At first, like most Enterprise Architecture (EA) efforts, these were IT centric, both in terms of participation and perspective.  However, as we have been suggesting for years, prepared IT Enterprise Architects took advantage of the interest of senior executive leadership by showing them their EBA and EIA work.  Usually in combination with a focus on major strategic initiatives, the models created for EBA and EIA shed some light on the complexity and interrelationships of the major strategic initiatives.  Senior leaders not only took notice, but embraced the usage of the planning concepts and artifacts long espoused by IT Chief Architects in the strategic planning context.

Stay up-to-date with the latest news