The importance of a name
Enterprise Architecture is a young science. I was reminded of that today as I sat through a presentation by a Garner analyst, listening to details of "EA Best Practices". Part of the presentation was this interesting statistic: of the companies surveyed with EA programs, 75% of those programs were less than five years old.
That doesn't mean that five years ago, there were 75% fewer programs. It means that most programs don't stick around for more than five years, because EA is difficult to do well, and it is pretty difficult to keep business and IT stakeholders actively engaged through the years where the program shows progress by keeping bad things from happening (which is pretty tough to measure).
So, making an EA program is hard, and keeping it running is hard, and you often find yourself just trying to keep the "value" moving.
So you really can't waste time making things up. You really can't waste time trying to invent things that already exist. There isn't any time. You have to show value. Put up or shut up. The people in EA are valuable to the organization. It is painful, to the organization, and sometimes to the architect, to take these super talented people out of roles where they create systems and put them into roles where they keep systems from being created incorrectly.
So when you find an artifact or heirarchy or model or tool that you can use, use it. If it makes any sense at all, and can save you a week or an hour, adopt it. It is easier to adopt than create. It is easier to buy than to build. Creating a model from scratch should be a last resort.
So if your company has adopted Zachmann or TOGAF or Gartner or one of the other EA frameworks, and an artifact can be pulled out of a different framework and used, don't worry about the source. As long as the taxonomy doesn't conflict, and the model is useful, just use it.
Continuously improve (refactor) your program in small increments. Deliver value in short regular intervals. Listen to your customers, write up stories that describe what they need, and deliver it.
Sounds like agile development? It is. Only EA style. Agile EA.
Now, that's a name I can live with.
Comments
Anonymous
March 13, 2007
pardon my ignorance, i'm new to this. What's a EA Program? I see a handful of references on Google that use the term, but I can find no definition.Anonymous
March 13, 2007
sorry about that. The first sentence should have been "Enterprise Architecture (EA) is a young science." My information architecture collegues would make the same point (and they have): always define an acronym before using it. My bad.Anonymous
March 14, 2007
thanks, but i guess the term "EA programs" is still a valid term. What does it mean?Anonymous
March 14, 2007
Oh... different question. Sorry about that. I clearly need more coffee (that's my excuse today, anyway). An EA program is a long term project, of sorts. You take a team of bright, committed, idealists from both within the IT group and from other companies, pull them together in a team that reports to the CIO, and you make them responsible for guiding the requirements that will be placed on the IT projects so that, after a while, the IT applications, data, and technical infrastructure is agile for the business. Making someone responsible for something doesn't mean that they will accomplish it. You could make Brad Pitt responsible for World Peace, but it won't happen unless he has a "way" to actually do it. Same with EA. We can't deliver an agile infrastructure unless we have a "way" to connect to projects, figure out what to deliver, when to deliver it, who to deliver it to, and how to make sure they listen. All those bits that describe the "way" to end up with an agile infrastructure... that's the EA program. It is processes, templates, practices, training, models, and standards, but first and foremost, it is business executives who believe that (1) this is a problem worth solving and (2) EA is a good way to solve it and (3) the right people are doing the right work. Like I said... this is hard.