Enterprise Architecture

John A. Zachman presents an framework (http://www.zifa.com/framework.html) for developing an EnterpriseArchitecture which makes a lot of sense.

Here is a definition I got from the Federated Guide To Enterprise Architecture: An Enterprise Architecture is a strategic information asset base, which defines the mission, the information necessary to perform the mission, the technologies necessary to perform the mission and the transitional processes for implementing the new technologies in response to changing mission needs. An enterprise architecture includes a baseline architecture, a target architecture, and a sequencing plan.

We've all seen them. Many of us have even been on them. You know the teams I mean: Enterprise (or Corporate) Architecture teams responsible for... what are they actually responsible for? "Setting technology direction"? "Establishing best practices"? "Dreaming up unrealistic ivory tower standards"? Oops, that last one just sort of crept in. :)

My question is this: what are valid goals for Enterprise Architecture Teams, and what are useful, productive activities that will help them actually achieve those goals?

Having worked in the financial industry all my career, I have a sneaking suspicion that perhaps these teams make a lot more sense/are much more functional in technology-producing companies.

How can we achieve the NobleGoals? that we all aspire to in a real world of poor communication, inter-departmental conflict, and cynical realism? -- BillBarnett

What's an Enterprise Architecture Team? -- rad

Answering that question might be a good summary of the intent of this page. :) Ideally an Enterprise Architecture Team is a group of highly skilled IT specialists brought together from across many different business lines, charged with setting technology standards and driving their adoption by business lines. They must be senior, technically talented people who can interact with senior management, technology leaders, and individual developers on many different teams at the same time. They frequently have the responsibility, but not the authority, for StandardsEnforcement inside large corporations. They are a frequent fixture of large corporations, but often add little or no value, being perceived as ivory tower bitheads or intrusive control-freak product police. Or both. -- bb

We could have a try at "Extreme Enterprise Architecture".

Have management write stories, telling you what they want in their enterprise architecture. For instance "Adopt a uniform security infrastructure scalable to double our current total number of employees", or "Guarantee downtime of less than one hour per year across all our Web applications".

Next have them write acceptance tests for the technologies you might want to adopt, and which formally specify what the high-level Enterprise Architecture requirements actually mean.

While you're waiting for that to be done, put half a dozen applications in production; if those get the job done, refactor the actual Enterprise Architecture out of them.

That's a very interesting approach. Especially because upper management is so frequently unclear about what they actually want the team to accomplish. I especially like the acceptance test concept here for exactly the same reasons.

If you were the CIO of a large company, what would you put as your most important stories? -- bb

Not to take anything away from stories, but I believe user stories are about requirement only, and you can discuss the role of architect independent of the responsibility to ferret out valid requirements. Maybe not, but here's an example. We run an entitlement database. Users and management just know that they want permissions turned on when they request them. Left to their own devices, they copy data rampantly, creating way too much to manage and bloating the data stores, leading to compromised performance. The application let them do that. Now they know they have a performance problem and a performance requirement, but they know not what to do about it. Enter the architect. (You fill in the rest.) To summarize, the architect's role is to see the better solutions for problems, once the problems are known. Essentially, it's the exploitation of information theory. -- WaldenMathews

Good example, Walden, thanks! So, one of the roles of an architecture team is to provide a pool of senior consultants who can be air-dropped into projects either at project initiation to point them in the right direction, or at technical crisis to help navigate through. The value that this kind of consulting brings varies over the life of the project, and it doesn't make sense for each project to pay for this kind of expensive resource throughout it's life. So the consulting pool allows project teams to "time share" these high-octane architects.

By putting these architects in a central pool, you also have an opportunity to develop a common technical vision of how applications should be designed and delivered. It should be possible to express requirements for this "service" as a user story, shouldn't it? Anyone care to take a stab? -- bb

(See WriteItOnaCard.)

I find myself in general agreement with Walden. I would emphasize more that Architect in this sense is a role, not a separate function. This might be a critical problem with the notion of an "architect pool". An enterprise architect who does nothing but enterprise architecture is at risk of losing touch with the operational realities she is supposed to address.

That is absolutely a risk. One way to mitigate it is to make sure that the guys providing this consulting service spend some percentage of their time doing "real" development work - either in service to the specific projects they are working with, or developing key infrastructure/common components. IMHO the benefits of providing this service at a consistent level and with a consistent technical vision justifies managing the risk of them becoming irrelevant. What do you think?

Part of the architect's mandate is to see, more clearly than might the people involved on either side of the business-development divide, what sort of high-level requirements could, if they were implemented using the standard story-driven scheduling tactic, result in overall improvements. Call this the consultancy "sub-role".

Once a provisional list of such requirements is established, it is up to business to decide how they should be ranked, formally express the acceptance criteria which determine that such requirements are indeed met, arrange for acceptance testing of the criteria, etc. The relevant "sub-role" of the architect in this process is strictly analogous to that of a developer in an implementation-level XP team - the mission is to discuss the stories with business, estimate implementation costs, etc.

To be consistent with XP values, though, this should result in a "sign-up" process; if you estimate "adopt a uniform security infrastructure" at, say, 5 points, you assume responsibility for meeting the acceptance criteria within whatever time-frame "5 points" translates to.

You must put your money where your mouth is, and I would expect that to mean, specifically : go meet the application teams, find out what would and what wouldn't work for them in the area of security infrastructures, find out how many implementation-level stories it is necessary to revisit or write from scratch to achieve the solution you have in mind (which is the simplest that could possibly work, and leverages as much as possible of the application teams' work). Maybe, possibly, you will find yourself acting in a "customer proxy" sub-role with respect to application teams at this point.

That is why the architecture team should build the key infrastructure to make these strategic choices incredibly easy for project teams to make. Gives them hands on work with the new technologies so they don't have to work from marketing presentations and vendor hype. That is also why it is important to "sell" this infrastructure to project teams rather than try and enforce/police it. This ensures that what is being built solves real world problems in a genuinely useful way.

At all times you are in touch with your customer and informing them of the difficulties and of the successes. The acceptance testing systems serves as the main communication medium for "documenting" the process. In fact, these testing systems probably don't look much like implementation-level ATs - the image I have in mind is that of a "wall chart" tracking conformity levels.

In a different instance of enterprise-level architecture, one I have some (though limited) experience with, I imagine a "wall chart" which measures a Web site's downtime as measured by redundant monitoring from various network locations, which do implementation-level testing such as pinging the server, grabbing some content- or service-type pages and doing regression tests on that, etc. The story "guarantee downtime of less than one hour per year" has an associated test which passes when total downtime in any one of the previous three months is less than five minutes. This could be refined, e.g. downtime in a given week which lasts between two and five minutes switches the status light from "green" to "orange" as a warning signal.

This sounds like another, more specific, and probably valid architecture goal: Implement architecture/infrastructure to minimize downtime, or ensure appropriate availability, or something. One process-driven IT redesign I lived through ended up with an entire department called Manage Availability. This as more of an infrastructure role as opposed to an (application) architecture role. But very similar, with lots of overlap

It seems to me that an Enterprise Architect is going to do three things:

Create a common approach to problem solving and implementation across an org Ensure reusability of components (such as security services) Mentor individual projects in the use of these techniques and components

With the common approach task, I'm thinking of the case where an architect has discovered that a business has a core set of business abstractions that a large number of software systems need to use; for example, a customer and account abstraction in a banking domain. A common approach to manipulating these things may be 'Use SOAP to talk, in this way (protocol) with this component (interface)'.

The reusability task I usually see being similar to that detailed in Software Reuse (Jacobson, Griss, Jonsson), in which the architect becomes responsible for identifying common behaviour in multiple existing applications and is then responsible for driving the abstraction of this commonality and the promotion of the reusable component that ensues.

The mentoring task is partially a case of promoting the common approaches and reusable components, and tying them together to help solve particular problems. This is similar to a standard architect's role, but with a holistic bent.

I believe that where a project can use existing enterprise architecture it should do so, and be guided by the enterprise architect, and where it can't the enterprise architect should focus on the project at hand.

I really like the idea of a pool of such architects within an organization, but I disagree with the no power to enforce stuff comment at the top of this discussion. I truly believe that someone who has a good idea and who can present this in a meaningful way has a lot of power. Generally, enterprise architects are listened to by everyone involved in a project; the developers are often interested in the experience of the architects; project managers respect the wisdom of the architect; and management pay so much for these people that they often realize that it costs to much not to listen to them (obviously, this isn't always the case, but in my experience it generally is).

-- BryanDollery

...and management pay so much for these people that they often realize that it costs too much not to listen to them.

Isn't that exactly backwards? ;)

That's a perfect description of how it SHOULD work in an ideal world. Unfortunately, the reality is often exactly opposite. Developers resent the title and all-to-often high egos of the architect and resist his decrees, project managers are threatened by the loss of control and insist the recommendations will never work or can't be implemented quickly enough, and management are so focused on immediate project delivery they give lip service to the strategic goals of architecture but always support the project managers in the end. Sad, but true. -- bb

Would you agree that the goal of having an EnterpriseArchitect isn't that the Architect should have a lot of influence or power, but that the Architect should help the organization meet its objectives? And that whatever influence the Architect exerts is justified only insofar as that influence is useful in meeting objectives?

Many people wrongly assume that Enterprise Architecture is software development on a larger scale. This is simply wrong. It is about realizing the strategic business goals of the enterprise through the use of technology.

For those interested in learning more, check out the book: The Practical Guide to Enterprise Architecture - http://cabobble.com/products/productdetails.aspx?ItemID=0131412752

-- JamesMcGovern

Issues about the definition of the term can be found under EnterpriseApplication.

Those definitions don't seem to include the one to which James was referring. There are two types of EnterpriseArchitect in the world

- those that architect Enterprise scale applications. For these people the discussion under EnterpriseApplication is very applicable

- those that work at a strategy level across the entire business

The strategy level work is almost non-IT work. It's exceedingly difficult (bordering on impossible) to achieve IT alignment with the business without forcing business change. This means that any work done by an Enterprise Architecture team (reporting into the CIO, CFO or even CEO) must be done in conjunction with the business team(s) responsible for BPR. This is one reason that most of the Enterprise Architect jobs that need ToGaf are with Management Consultancies - they engage with a business at a business level, and pick up the IT strategy as a subset of larger business change.

Does this mean that Enterprise Architects are sat in an ivory tower? I'd hope not. Part of the role is governance, ensuring that project teams are not deviating from the IT strategy (as expressed through an enterprise architecture). To do governance properly they need constant communication with the people working hands-on. I've noticed that the more senior I get, and the better I get at software engineering, the more important communication seems to be. I'm sure it's always been that important, it's just taken me too long to realise this. Now at the level of Enterprise Architect communication is the primary role. More change happens as a result of merely talking to people than all the analysis and documentation that I do. (Yes, that's Agile. If I don't document the Enteprise Architecture the board can't deliberate and agree to it. Documentation is one of my deliverables)

The role of Enterprise Architecture has been around forever. Zachmann did attempt to pin down what it meant, what was involved and how to do it. TOGAF offers an alternate approach. Organisations such as the US Department of Defence have their own variants. Despite this, and in conjunction with much of IT, this discipline is in its infancy. I've only been doing it for a couple of years, and I'm already finding limitations in the processes, standards and approaches currently documented.

But back on topic, it's a very different discipline to Enterprise scale ApplicationArchitecture?.

-- StuartScott

DoesItMatter anymore? I attended a seminar a few months back, given by a doctorate candidate who specialize in EnterpriseArchitecture. Basically I came away with the impression that without StrategicAlignmentOfItProductsAndServices, all the talk on EnterpriseArchitecture is just another oxymoron. Enterprise do not have architecture (neither business nor IT oriented ones) because Enterprise need to adapt to survive.

All enterprises have an enterprise architecture. Even when they didn't plan it. Does it matter? Only if you're serious about long term cost reduction and avoidance, and business enablement. Having a business constrained by their IT systems is rather painful.

Sorry I can't help it...

  __________________          _-_
  \________________|)____.---'---`---.____
               ||    \----._________.----/
               ||     / ,'   `---'
            ___||_,--'  -._
           /___          ||(-
               `---._____-'

What websites do enterprise architects use frequently? For work, consultation, reference etc. -- Ian