Everyone has patterns in their EA work. For my "ETA Patterns: A Practitioner's Guide" presentation this afternoon at 4:15, I hope to tease out different kinds of patterns, then zero in on the kind that is focused on the complete set of technical parts that are needed for common application platforms. Such end-to-end blueprints are useful. But, they aren't easy to create or use after you've created them.

What I want to do is make sure EA teams keep in mind when doing this kind of work is how important it is to think about the team you set up to do the modeling and how you manage that effort. If you're not careful, you end up with ETA patterns that no one really wants to use. The role of the EA or ETA lead for such teams must be to define a representative team, define a reasonable and well understood project plan, then manage these models over time like any other standard: with life cycles and upgrade paths. In working with many clients, I've found a few key things can make a big difference in success.

Join me to see what those are, and share some of your own.

Submit a Comment | Permalink

I still think its the Business IT group that manages the business architecture which evolves in an organic manner based on business needs and issues. The committees can only guide the standards.