Monthly Archives: April 2005

Weighing In On Being A Good Enterprise Architect

So in James [url= new=true]McGovern's Blog Entry[/url] 3/19/2005, James provides his wisdom on being a good Enterprise Architect. This drove me to think about what makes a good Enterprise Architect, something I needed to do for my upcoming presentation at SD Best Practices, Enterprise Architecture 101. James' wisdom covers many of "people" aspects of the job, and you'd do well to listen to him. However, I wanted to weigh in on the technical side of the role.

I mention in my "About JP" page (see right), my Ray Kroc philosophy of the software industry. There is something to having been on the buy, sell, consulting and analyst sides of the business. I feel that this is one of my greatest strengths when designing systems. I feel that I understand the impact on the system from these different perspectives. WIthout one of them, you have a "blind spot" that could limit the effectiveness of your system. It's like a doctor that needs to intern in each specific type of medicine so they become well-rounded. What they learn in one practice influences how they diagnose in entirety.

Working with IASA, we're trying to put some scope around the field of software architecture. Certainly, it is an animal that doesn't want to be tamed. However, we have been using the analogy of a building architect a lot. However, feeding from my previous paragraph, I believe we are more like doctors. We need to poke and prod and take blood from the business so that we can heal their business processes. Enterprise architecture is a lot like medical diagnosis and our frameworks are nothing more than proactive measures for better health. Let's face it, organizations have lived without SOA for 35 years, but with it, things will cost less and get done faster. It's much like the Americal Medial Association telling us that walking is good for us, eh!

Finally, being a good Enterprise Architect requires you've actually implemented some very large-scale, highly-available systems. Without having actually done this three or four times, you cannot truly imagine (because as an architect you have to imagine the system running in your head in order to think about all the places requiring reinforcement) how the system will perform. Thinking that an ESB is going to fix all your communications problems because you read [url= new=true]David Chappell's book[/url] is not the same thing as having rolled out a large-scale MQSeries solution for integration and understanding the performance requirements related to hundreds-of-thousands of transaction per minute.

It seems everyone these days wants to pass themselves off as an architect of some type or another. Architecture requires the ability to think abstractly. If you're not a good abstract thinker, but you know how to build systems, then you're an engineer, practitioner or implementor. The architect has the ability to see the finished product working in their head. The architect has to be able to analyze their own creations for the flaws and correct them. The architect has to have vision for what a system could be in the future and prepare for that inevitability.
An architect has to be able to develop models that help others understand their vision, much the way scientists have modeled the galaxy to understand blackholes. There are some really good programmers out there, but they can't model to save their lives.

But, here's what I think is the most important aspect of an Enterprise Architect, they can translate between the business and technology worlds. They are in essence the equivalent of a UN interpreter for two worlds that have never understood each other. Each with a language as different as Mandarin and English. Can you communicate your ideas and vision to the business leaders in your organization so that they lead to changes in the business?

If you have the traits I speak of above, then perhaps you should consider the role of an Enterprise Architect. If not, be the best darn engineer you can be. We need you to make our visions reality!