Sunday, January 22, 2006
The Discipline of Enterprise Architecture
I agree that most methodologies are sold by consulting/analyst firms, academics, and book authors as the Holy Grail that will cure most, if not all ills in an IT organization. That, simply put, is largely sales and marketing fluff. Then again, the main product these folks sell isn't services and software, its hope. And hope is not a strategy.
The architecture community is having a hard time in a number of areas due to the following:
- Until we achieve some kind of definition or boundaries on what enterprise architecture is (and is not), it's going to be tough to come up with bodies of knowledge that directly drive process and thus drive discipline that leads to successful outcomes. Being too development/technology-centric or the same on the business side won't cut it. Frameworks are great, but knowledge about how to successfully use them in an economic and expedient manner is even more valuable.
- Economic value to the business from our efforts must always be shown, not just technical value. Those who cannot or will not do this must also realize that the business has every right to question why the architecture function exists in the organization.
- Knowledge and talent are separate from the ability to successfully apply them to business and technical situations in an organization. That usually requires discipline usually represented as processes and procedures. Does it really matter if such processes wre developed by a consulting firm or gleaned from a book, if they work well?
Enterprise architecture already has a wide body of knowledge, but it's very disorganized due to lack of agreement on definition, and with that shortcoming, a lack of discipline to practice it to the benefit of all. I think that we'll collectively get there eventually, but it will be a long march.