Generally speaking, I believe the other roles in the organization will map either to the “Product Manager” or the “Lead Developer.” The rule of thumb I would use is to ask the question “Is the person acting as a stakeholder?”

When the answer is yes, I would look at their “requirements” in the context of the current project – are those needs reflective of goals to be satisfied by the project, or constraints to be enforced? When they are goals, I think product manager. When they are constraints, I think lead developer.

What do you think?

Scott (@sehlhorst on Twitter)

I just stumbled over this blog entry — not sure you will see this comment since the article is a bit dated.

I am doctoral student doing research on goals and architecture. I really like your diagram, and was wondering how it would extend to other roles in the enterprise. Such as enterprise architect, middle and upper managers and also customer and 3rd party organizations. I think i will try to extend the diagram in these directions.

thanks,
Dan

I agree that EA is a loaded term, and many people put different definitions behind it. In general, I view an architecture like this as a system of systems. The overall lives indefinitely (practically speaking), while the individual applications come and go. The business uses of the system also change over time.

These two dynamics make it different from managing requirements for a single application. A large enough, modular application may exhibit the same characteristics (think of the evolution of Lotus Notes / Domino, for example).

I’ve done the “map the process to the architecture” functional analysis work before, and I believe it is critical to the success of any large architectural initiative. It is also valuable to any small-scale initiative. For example, the duplicate code you mention as a legacy in your example may have been avoided by doing that analysis before the second (or third!) version was added into the ecosystem.

I need to read the BEA white paper to address your later comments.

I like the Zachman framework – and I like Zachman, too – I had the honor of meeting him last year at the IBRF conference. For an organization that is not using that approach, it can be an overwhelming framework to explicitly stand up. But you can easily use it to guide the “do these things” and “do this next” discussions. Keep a printout of the chart at your desk, and once you’ve started covering (or intentionally excluding) activities in each box on the chart, you can more easily introduce the concepts.

I can’t speak anecdotally to the tradeoffs of using Zachman over the long haul, because I haven’t worked on an architecture (for a single client) for more than 18 months at a stretch. I’m usually brought in to either stand up a new solution, or to help implement significant changes to an existing one. I also haven’t worked on a mature architecture that had been managed over time within the Zachman framework before I became engaged.

If anyone out there has comments about the challenges of managing a single ecosystem for more than a couple years, I’d love to hear them. The folks I’ve worked with have mostly treated things as a series of “critical business initiatives” that are addressed serially – with lesser investment in the long-term view.

I’ll take a look at the BEA stuff – hopefully in the next week or two – and follow up.

Enterprise Architecture is such a loaded term with dynamic definitions while having has so much promise, and so much risk. In a large enterprise with a great deal of legacy applications, often duplications from various mergers, how applicable is the process of Requirements for EA? The efforts involved to produce valid requirements in such an environment are immense, and thus may not get funding. Additionally, change is the constant in IT so when the requirements are completed they will need updating. This assumes there was no “analysis paralysis” in the effort to begin with. Thus in the large enterprise an EA requirements approach may not be viable.

I would also be interesting to hear your thoughts on documenting Business Process then mapping to the Applications as in the BEA white paper ( http://dev2dev.bea.com/pub/a/2006/03/enterprise-architecture.html ), and to some extent the Zachman EA framework (http://www.zifa.com ).

Perhaps your comments were taken out of context from a holistic EA solution. I would like to here your comments on this approach. Thanks.

thanks in advance!

In situation 2, there was already a “requirements gathering phase” that lead to the existing architecture. In the time since then, the business has changed (and the architecture has probably changed too). The question to drive after is “What work needs to be done, to provide support for what the business needs to do now and in the future?” There will be cost-benefit analyses associated with the use, leverage, or enhancement of each application in the logical architecture. That’s how we’re approaching it now, and how I would suggest that others approach it.

2) I wonder what you think about the situation: someone works at a company and finally finds out there already is a quite extensive application ecosystem and now calls it enterprise/application architecture. he or she will not start by a couple of requirements to ‘build’ the architecture, because it’s already there. how will he/she approach the task of building, maintaining, documenting the architecture? and how would the fellow BA help with it?

Thanks for your comments.