I've had a couple recent experiences with large companies Enterprise Architecture (EA) practices and generally found that one of two scenarios exist. Either they have a robust and well defined EA methodology and are strictly (or at least have the illusion of) adhering to it, or they understand what EA means but have chosen to only implement or govern tactical pieces of it.

Large companies generally have the staff and resources available to support and maintain a corporate wide EA discipline but what about small to mid-size businesses? It is likely impractical to expect smaller companies or organizations to implement and promote all of the processes and deliverables that frameworks such as TOGAF or Zachman prescribe. However, there are a few important items that I will call out that I have seen be extremely effective when implementing EA.

First is understanding what you have. This seems obvious, but most of the clients I visit do not have a good feel for the current state of their IT environment and how the systems that exist in the landscape are actually fulfilling business needs. Assess what you have at an enterprise level in more generic terms and domain specific areas (such as sales, marketing, operations, etc.) at a more detailed level. The goal of this is simply to understand and to be able to communicate to IT and business what you have before you even begin to think about what needs to change or be added to support new business requests.

Second is the identification and documentation of core business processes. One could argue this isn't purely an EA focus area, and I will not disagree with that statement, but understanding your current or target business processes is essential to the next critical item in the evolution of an EA initiative. Technology projects for your organization need to be able to directly relate back to what your business does on a day-to-day basis. Without the understanding of what it is the business is trying to accomplish it is extremely difficult for projects to have a net business positive impact.

Finally it is important to define and communicate your target vision. Depending on the agility of your organization these targets can be as short at 1-2 years but more realistically these are 3 year or longer visions. An argument was made to me that a company didn't know where they wanted to go in 3 years so all that could be focused on was the short term. This is exactly the type of situation you want to avoid, unless fighting fires or always being in a reactionary position is what you live for. Target architectures define how projects or initiatives align with the business processed identified in step 2. They define the road-map for how to achieve the business goals identified and the current state analysis is a key input in the equation. Some target architectures will only address modifications to or efficiencies in current applications and systems while others might introduce new technology or systems to meet new business challenges. Both are equally effective and can help define where cost cutting or capital expenditures will have the greatest impact.

The important thing to remember is these things can all be achieved without diving head first into a full EA practice. Small and mid-size businesses generally thrive by their ability to be efficient and agile. A full EA practice may not make sense, but an applied approach such as mentioned above can help instill rigor in IT planning and provide immediate benefits.

EA can most definitely work for small business.