Check out this post as it is a good read to at the very least give a sanity check on your EA efforts. I also find being the "Devil's Advocate" at times is also healthy. Always hanging out on the band wagon for too long can cause of a lot of damage.
Here is a snippet from Dave's post:
Truth-be-told most enterprises are not spending that much on enterprise architecture. Indeed, for most of the Global 2000 there is a lone architect, with a couple of staffers, that has no budgetary nor referential authority, thus no results. You can't "influence" your way to success, you have to have some kind of hammer drop on somebody's head if they don't follow the core architectural principles…it's called governance.
To take a step back I really like articles that challenge the ideals of a practice. For me there are some themes in the article that make a lot of sense. These include:
EA Viability - If EA is broken evaluate if you should really continue it? Sometimes the answer is yes, sometimes the answer is tweak, augment, enhance, etc.
Architecture Governance- There needs to be "teeth" in architecture development processes. I can't emphasize that enough. However, what I do disagree with is the "traffic cop EA" or "dropping the hammer". That isn't productive and ultimately pushes teams away from EA. Let the auditors and compliance guys do that.
EA Authority - EA's have no budgetary or referential authority thus no results. I agree with the first bit but not the second. I can speak from experience that I was able to effectively change the organization by not having direct reports nor a budget. I was a trusted partner and a technology enabler. From a senior management perspective my job was to keep the company out of the Wallstreet Journal. This was attractive to LOB CIOs and above. But the common architect working on SOA activities valued EA's because they could help validate their thinking, mitigate risk and help with the design.
Validate the need for EA - "Perhaps it's time to send a message, and pull the plug . At least that will drive some change." I wanted to highlight this message because I think if EA isn't working for you, try living with out it for awhile. See if you revert back to that thinking or if there are business or technical drivers lead you back.
One last comment that I will make is that architecture in general is maturing. This is in the definition of what architecture is, the process in which we derive to an architecture and the role of an architect. With standards bodies such as the OpenGroup we are seeing a 230 percent increase in certifications and 50 percent of permanent IT jobs in the U.K. include TOGAF as a required skill set. This was a survey done by ITJobsWatch this year.
So even though I feel that EA is a great practice to have it's not for every organization. EA is a hard thing to do and most organizations iterate through several different models before they get it right. There is nothing wrong with that. At the end of the day you are tailoring it to your business needs. And if you do not need EA do not do it for the sake of doing EA. This is true of other processes like Six Sigma, ITIL, etc.
Thanks David for asking the hard questions and for your candid observations. Great stuff!
Tags: Enterprise Architecture
コメント