Tuesday, March 28, 2006
Should you trust consulting firms with enterprise architecture guidance
Several individuals provided private feedback on a previous blog entry where I suggested the agile community needs to grow beyond its founding members and reminded me of the fact that if this doesn't occur in a controlled fashion that words will be hijacked by larger consulting firms in order to sell things that the enterprise may not truly need. All of them agreed that the word agile has been distorted, overused and abused in corporate settings and therefore championing it nowadays may result in better buy-in at the expense of worse execution. They also asked me to think about the topic of enterprise architecture and soon how it to may follow the same path as the word agile...
I have always believed that Government enterprise architecture is a big fat joke! They literally got an act of congress (e.g. The Clinger Cohen Act) mandating enterprise architecture practices for all departments. If only in corporate America we were so lucky. Having to "sell" the value of enterprise architecture takes away from time to actually "practice" enterprise architecture. Folks in the Federal Government were blessed to have one pain point removed from their "process" yet missed the opportunity by turning it into big ceremony around the creation of bureaucracy and lots of comprehensive documentation that few people have actually read.
For the most part, government IT is outsourced to a variety of consulting firms who have a vested interest in extending their contracts indefinetely, not cooperating with other consulting firms in which they compete and otherwise making something take a lot longer than it really should. Of course, there are lots of folks that can find positive in a pile of negatively and spin it to make it look like a success, but we all know that reality states otherwise. It does beg the question of whether any form of enterprise architecture should be handled by consultants and what can corporate America see and learn from our government as to how not to do enterprise architecture.
I have spent more of my life as a consultant (distinct from contractor) than as a full-time employee of a large Fortune enterprise. I remember one project when I was a consultant where I worked on a trading system application and its strategic direction and it was supposed to take ninth months. We actually prototyped the system and got the traders to like it and agree to put it into production in four months and it was wildly successful. The client of course, felt that he paid for ninth months of time and made a stink, so the team sat around taking turns sitting in front of Microsoft Word cutting and pasting from a variety of third-party documents to create a set just for this client. Over time I have learned that lots of folks were later forced to read something that provided no value but did so simply because this was the process.
In other consulting gigs, I remember doing what I will refer to as "architecture by Powerpoint" which essentially was the savage practice of drawing "cartoons" type presentations that provided such a high-level view that it could not only describe the future state of your organization, but anyone else's as well without requiring changes. IT executives loved this practice. To me, this was a necessary evil in order to get to the next step. I remember on multiple occasions finding better ways that could help the client save money and to help them increase the producitivty of their staff but was met with resistance because they didn't really care. They already developed their own "pitch" to their bosses and changing things even for the better would result in confusion.
Fast forwarding to today, having seen both sides I have come to the conclusion that non-employees of large enterprises should only provide guidance in certain aspects of enterprise architecture but otherwise shouldn't be practicing it. If I had to recommend a few things to others considering hiring consultants to provide guidance, I would suggest that their backgrounds be probed for the following elements which are predictors of success:
| | View blog reactionsI have always believed that Government enterprise architecture is a big fat joke! They literally got an act of congress (e.g. The Clinger Cohen Act) mandating enterprise architecture practices for all departments. If only in corporate America we were so lucky. Having to "sell" the value of enterprise architecture takes away from time to actually "practice" enterprise architecture. Folks in the Federal Government were blessed to have one pain point removed from their "process" yet missed the opportunity by turning it into big ceremony around the creation of bureaucracy and lots of comprehensive documentation that few people have actually read.
For the most part, government IT is outsourced to a variety of consulting firms who have a vested interest in extending their contracts indefinetely, not cooperating with other consulting firms in which they compete and otherwise making something take a lot longer than it really should. Of course, there are lots of folks that can find positive in a pile of negatively and spin it to make it look like a success, but we all know that reality states otherwise. It does beg the question of whether any form of enterprise architecture should be handled by consultants and what can corporate America see and learn from our government as to how not to do enterprise architecture.
I have spent more of my life as a consultant (distinct from contractor) than as a full-time employee of a large Fortune enterprise. I remember one project when I was a consultant where I worked on a trading system application and its strategic direction and it was supposed to take ninth months. We actually prototyped the system and got the traders to like it and agree to put it into production in four months and it was wildly successful. The client of course, felt that he paid for ninth months of time and made a stink, so the team sat around taking turns sitting in front of Microsoft Word cutting and pasting from a variety of third-party documents to create a set just for this client. Over time I have learned that lots of folks were later forced to read something that provided no value but did so simply because this was the process.
In other consulting gigs, I remember doing what I will refer to as "architecture by Powerpoint" which essentially was the savage practice of drawing "cartoons" type presentations that provided such a high-level view that it could not only describe the future state of your organization, but anyone else's as well without requiring changes. IT executives loved this practice. To me, this was a necessary evil in order to get to the next step. I remember on multiple occasions finding better ways that could help the client save money and to help them increase the producitivty of their staff but was met with resistance because they didn't really care. They already developed their own "pitch" to their bosses and changing things even for the better would result in confusion.
Fast forwarding to today, having seen both sides I have come to the conclusion that non-employees of large enterprises should only provide guidance in certain aspects of enterprise architecture but otherwise shouldn't be practicing it. If I had to recommend a few things to others considering hiring consultants to provide guidance, I would suggest that their backgrounds be probed for the following elements which are predictors of success:
- Understands that IT/Business alignment is a rallying cry and not an indicator of change in skillsets. The business community needs great IT people. We can't all be spending time aligning with the business and someone needs to pay attention to strictly IT issues. Its all about balance.
- Some hands-on experience with Agile Software Development so as they can guide you into lighterweight ways of accomplishing the same goals.
- They should be speakers at conferences. The industry itself will tell you who is worthy of your time. It will also tell you if they have been successful in the past of truly articulating the value proposition of EA
- Is more aligned with Enterprise Architecture 2.0. The enterprise doesn't need enterprise architecture historians
- Has worked not only in a variety of industry verticals so as to provide cross-polinization but has worked for a wide-variety of size firms ranging from Internet startups to Corporate environments. The ability to understand the "business" and the stages it goes through is crucial as everything evolves.
- Has a strong sense of community and not only analyzes them but actively participates. The future state of the enterprise architecture is community driven and there should be a preference for those who have had an early lead.
