I’ve been moderately unconcerned with architecture for some time because of my ‘agile’ principles. Why? Architecture is the result of good engineering practices at the team level. However, who keeps their eyes on the road at an enterprise level?

What is architecture? To me.

Did you ever hear the story about the girl that goes into the doctor and pokes her elbow and says “Doctor it hurts when I do this” and the doctor says “Well don’t do that then”. This is basically what architecture is all about, for me. It’s about seeing a painful place in the structuring of all of your applications and infrastructure and making an effort to improve that.

            For example, if I have to change 3 classes for 1 software update that I have to do pretty frequently… then I probably could make some architectural refactoring to improve that design so that I only have to make one update.

            If there is an issue with a specific vended DBMS that causes many support calls then I might change my architecture to move over to a different DBMS.

How does architecture happen at the team level?

            Generally speaking, you start small by choosing what programming language your team members could do their work in the best. You might choose a specific hardware platform. You might choose some frameworks that have a core set of functionality that could save you time. You might choose a vended application that does the work for you (and maybe you’ll modify that).

            Once you have the tools in place, you’ll start writing code. If you’re doing TDD, the design will evolve from YAGNI and DRY one test at a time (or red,green, refactor). If you’re not doing TDD, then you’ll probably do some analysis and design up front (use case, uml class modeling, crc cards, or something like that to get an idea of what structures you’ll make in your code).

So now, the problem.

            You’ve got your great application architecture and it’s utilizing your Core software (or and ESB / SOA between that and you).  Let’s say you’re the first application to display enterprise account information. The ESB’s job is to just provide you data and then you provide the presentation, right? So you consider things like commas in large numbers as presentation and code it into the UI, you consider authentication part of the presentation and code that into the UI, you consider caching as part of the presentation and put that into the UI.

            Now some other team goes to create a new application that presents account information. They only see what’s in the ESB so they write all of those Cross cutting concerns AGAIN.

This is where the need for an enterprise architect should come in. This architect needs to be able to see that things are being repeated and to align business units and technology people into a common goal of solving this rework problem. Things like AOP can be used in java and c# to be able to wrap business entities and use webservices to provide the cross cutting concern (logging, auth, formatting, etc).

I wonder if this is really such an issue if you've implemented scrum of scrums in your organization since the highest level scrum team would be an enterprise integration team?