What does an Enterprise Architect do?

Software architecture has become increasingly complex. Keeping it simple is a challenge for today's Enterprise Architect.

In the 80s you bought an IBM mainframe or mini computer, set it up in a cold room and placed "dumb terminals" on the worker's desks. The user keyed data into the green screens and pressed enter. The Enter key sent the full screen back to the mainframe for processing. It was a simple model. Software architecture consisted of database, process, and report design.

When the personal computer was born things changed. Eventually the promise of a richer user experience resulted in the client/server model. This seemed good. The software at the client side could validate the data before sending it back to the mainframe thus reducing round trips and process time. Additionally the user could interact with the screen in a more direct way.

Unfortunately the support model was impossible to get right. Each personal computer was often configured differently, had different patches or a different install base, which wrecked havoc on the client side behavior. This became more complex as the Personal Computer clones came on to the scene. I remember asking vendors: "Has this been certified on IBM DOS or MS DOS or both?"

Eventually the client-side was pushed back into the web server and is now the standard for today's multi-tier architecture. The support model works well since the web server is also in the data center. The support team can have complete control over the hardware/software footprint of all machines in the stack. Of course. the user still wants a rich experience so java applets were introduced (remember those?) then java script and now AJAX was added. It's still a little complicated though. "What browser do you support?" is a frequent question I ask of COTS or ASP vendors.

Orchestrating these tiers, containers, and back-end systems is now what architecture has become. I heard another Enterprise Architect say that "to orchestrate" is what an architect does for local services but "to choreograph" is what he does for end-to-end solutions. I have to agree with him on that. We have become like the choreographer of Enterprise computing systems.

I just got off the phone with a recruiter who asked me what my day-to-day job looks like. He asked what kind of tools I prefer. That's like asking a cabinet maker which chisel he prefers. "Whatever gets the job done given what enterprise tools are in the box." I told him. I gave him the example of the ATS system I designed and built with a team of six. We used open source because The Home Depot didn't want to spend any more than $700k. In seven months it was up and running on the Internet and pumping through 15,000 employee applications a day to the back end systems. It was the simplest thing that could possibly work.

But the architect's job is not just about choreographing end-to-end solutions. His/her job is also about designing Enterprise Services (SOA). What are they and what must an architect do to ensure their reuse? Are there caveats to designing them?

Next time: The Promise of SOA

...dave
Sometimes it pays to stay in bed in Monday, rather than spending the rest of the week debugging Monday's code. -Dan Salomon