Thursday, August 16, 2007
Enterprise Architecture and the Love of Methodologies...
Enterprise Architecture as a discipline has suffered a long term identity crisis. It never seems happy to be itself but instead pretends to be the discipline it serves at the moment, or the discipline from which it has drawn the most members. First our discipline wanted to be like mathematics. What joy it is to reason with artifacts of pure thought. Then we were a science, off on a voyage of discovery with the scientific method at our side. Now we've matured to engineering liberated by certified processes and the love of frameworks.
Enterprise Architects are not architects nor engineers. At some level we are gardeners and journalists. Like Nicholas Carr, Rush Limbaugh or Michael Savage we want to be idolized and reviled at the same time and all work under deadlines. Luckily some of us have figured out that enterprise architecture and its notion of aligning with the business really is about letting junior folks actually design the systems which allows us to leverage our sage wisdom to provide editorial maintenance to key messages.
Other enterprise architects realize that their job is to scatter seeds, periodically pull weeds and spread lots of fertilizer. To call us anything other than gardeners and/or journalists is insulting to other professions. Enterprise architects should stop talking about Business/IT alignment and talk more about publish or perish.
I wonder when we will stop being process weenies and start focusing on critical knowledge we need to make our enterprise truly successful? Frameworks for the most part serve others outside the architecture community and provide little, if any value to architects themselves. What if enterprise architects were to help others (internal developers and software vendors) build valuable, higher quality working software?
I bet if all the enterprise architects for one day, simply took time out and looked at systems currently being developed, they may find many missing architecture definitions in the following areas:
- Software architecture and specifications including language use, library use, coding standards, memory management, and so forth.
- Persistence architecture, including databases and file handling mechanisms.
- Systems management and performance management architecture
- Application security architecture, including not duplicating user stores, support for externalizing entitlements, thread/concurrency models and the notion of secure coding practices
None of the popular frameworks helps enterprise architects uncover risks to scale, domain knowledge, technology or complexity as these things tend to emerge and aren't usually known upfront. Likewise, they also don't uncover implicit and unresolved issues in the architecture due to gaps in systems engineering. I suspect that we get so indoctrinated into using certain notations and fall in love with a standardized perspective that we don't realize that we may need additional ones...
Links to this post: