Hot Spot Columns
Role of the Architect Columns
Architect's Role in Dealing with Complexity
by Ruth Malan, Bredemeyer Consulting, January 2004
To the old adage “If it ain’t broke, don’t fix it.” David Molden (2001) adds the controversial advice “If it is broke, don’t fix it, build a new one.” He recommends focusing incremental improvement efforts on what is working, and replacing what is not working. While it might be hard to decide what is “broke” versus what is “working”, it is useful to keep this piece of advice in mind. Some things just clearly are broken, and trying to make incremental improvements saps resources without any chance of making the kind of difference that is sought.
In the Enterprise Architecture space, we see team after team becoming overwhelmed by the task of documenting (and then keeping current) an overwhelming inventory of current systems (attempting to go after the “capture the current state” problem). Let’s put it bluntly for effect: If you have a “dog’s breakfast”, don’t spend all your resources documenting your “as-is architecture”. In the best case: all you’ll be able to do is tweak your current state. In the worst case: you’ll enter a never-ending cycle of trying to capture the dynamically shifting state of the mess.
Go after something that has a good chance of success, that is worth doing with this enterprise-scope opportunity. For example, you may want to mandate Java as the development language across the enterprise. It will bring about good things--more reuse, more mobility of the IT workforce around the company, better quality, etc. You know the incantation. But, is it appropriate for every group in the enterprise, and does the enterprise only get the benefit if every group co-operates? Remember, if you are broadly and forcefully resisted, this will reinforce a culture of resistance to EA. Will your decision be adopted, or will it just be ignored under schedule pressures and general organizational inertia? If so, it will be chalked up as another one of those EA failures, creating a legacy of failure.
Be strategic, focus on something that will have high impact and be achievable.
Which is not to say you should not aim high! Bear in mind, even the remarkable can be achievable, if you are passionate about it, and you can convince those critical to the change that it is worth it. The best way to ensure this, is to focus on something that truly is worth it.
Commentary Added 2/6/06
One architect politely asked me if they did what they could to inventory their technology in one day, would that be a good thing. I wholeheartedly agreed. My quibble with Enterprise Architects spending weeks if not months on this exercise has to do with this use of talent. Yes, the Enterprise Architects should come up with classifications and with guidance, and steer the effort to understand the current IT assets and distribution of technologies across the enterprise. It is important to be able to substantiate claims about the state of the mess we're in, to show progress, to provide input to IT portfolio planning during the business planning cycle, and to provide guidance through ongoing investment decisions. But don't get drowned in this task. Get out front and lead.
Enterprise Architects are strategic assets. Those who have risen through the technical/architect career track through unique and scarce talents are better employed doing highly strategic work building enterprise capabilities that will differentiate their organization. Or, if the very competitiveness of the business is at risk because its foundational capabilities are falling behind, then the enterprise architects need to figure out what needs to be done to rebuild the core capabilities so that it can compete into the next decade.