He begins the series by citing Lens Fehskens of the Open Group, who cites three levels of maturity that IT organizations can progress through:
Level 1: Getting technology to work at all
Level 2: Getting technology to do the right thing for the business
Level 3: Adapting technology to do the right thing efficiently
Fehskens argues that most companies are trapped at level 1, basically spending their time putting out fires. Woods argues that the “Raw Technology Persona” dominates at this level – where technology is implemented for its own sake, as opposed to for the benefit of the business. This topic, by itself, warrants extensive exploration, but I’ll leave that for another time.
More interesting is that the development of an architecture can provide the means for an IT organization to escape from level 1. This is because a properly defined architecture can provide a roadmap that describes both how IT is creating value for the organization and how new technologies and opportunities can, or can not continue on that path. If a technology doesn’t fit in the architecture (or presumably any system vs. a specific technology), the decision can be made to not pursue the technology. Of course, it is also imperative that everyone understand that EA is a process, and an expensive, difficult one, at that.
This last bit in the first article really caught my eye. The development of a proper strategy should be difficult and time consuming, and nobody should get locked into a non-changing strategy. The strategy, then, should primarily be about the strategy. Make the development of a long term, progressively elaborative strategy be the goal, and everything else is more likely to fall in line. I recently was speaking to a friend who indicated their company has agreed to a 5 year plan to harmonize 18 of their sites. I was amazed, because most companies don’t really work in 5 year horizons. Frequently they work in next quarter horizons. If they stick to their plan, I’ll be even more surprised.
The second article goes on to describe how the architecture leads you up the ladder, because you begin to understand what the business needs, and how technology supports that. Over time, as the architecture and organization mature, the vision becomes even more cohesive, where the interplay between technology and the business is viewed across portfolios and the entire company.
Woods also points out that there is a risk that, owing to the complexity of the methodologies (TOGAF occupies 750 pages), organizations can become absorbed in the process, and make the entire exercise about it instead of the desired result. Once again, the technologists can find themselves implementing a technology (or in this case a methodology) for its own sake.
Perhaps, then, the first step down this road is not convincing senior management to fund the process fully, nor to implement an architecture program. Perhaps the proper first step is for all of us technologists to agree that the success of the business is what is most important.