Archive for October, 2009

Q & A From Next-Gen EA Teleconference Oct 09

October 28, 2009 Leave a comment

Jeff Scott and I presented a teleconference entitled “Next-Generation Enterprise Architecture” last week (available here). It was a lively session with a lot of material on our side and a lot of questions from attendees. We focused on the questions over the phone in the live session and decided it was best to handle the written questions that came in via the Webex chat in a blog post.

Two closely related questions kicked things off:

“How are enterprise IT organizations rationalizing EA’s role in Demand Management with ‘traditional’ Customer Relationship Management?”

“Traditionally, aligning IT strategy to business strategy is typically the job of Head of Application or Application Client Relationship Manager.  EA was more a technical advisor.  Are you advocating the marriage of these positions?”


Traditional IT customer relationship management has been handled by application managers or dedicated client relationship managers. Unfortunately, this arrangement has perpetuated a business unit silo approach down into the IT organization. Demand mangers have done just that: managed the demand their business clients present them with adding little if any enterprise perspective to leverage existing resources or collaborate on new solutions. Relationship managers have done a good job collecting all of the requests, prioritizing them, and sequencing them into the solutions delivery workflow. What is needed is more demand “shaping” and less demand “management.” And this is where EA s can help. Using business architecture tools and techniques, EAs can help ensure investments are being optimized across the business unit silos.

Forrester is seeing leading edge EAs working with business leaders at a conceptual/strategic level to determine what needs to be done with an enterprise perspective, rationalize the needs at the enterprise level, and then help translate the needs into business unit aligned initiatives that can be managed by the traditional demand managers. This shift does require that EA move from being technical advisors to strategy advisors.

EA's Value To The Top CIO Priorities

EA's Value To The Top CIO Priorities

Next question:

“Given a mixed environment of legacy, COTS, and custom solutions, supporting a changing business environment and delivering precision IT says EA has to not only cover business/process architecture, but also the information architecture. Where / how do you see information architecture coming together?”


Now that’s a big question and its generally the main subject of my (Gene’s) research agenda for the next year or so. In the distant past, organizations attempted to pursue information architecture and wound up mired in a boil-the-ocean initiative that never ended and always seemed far from producing value. The failure of these initiatives made people very cautious about starting them up again. But all the attention on business processes brought about by the popularity of BPM suites as well as decomposing processes into services to pursue SOA has brought information architecture front and center. All processes act on data and focusing on process without getting the data right just doesn’t work (and there are other forces at work also raising the priority of information architecture). The only way for information architecture to come together is through ownership and conscious effort. We’re strong advocates for the EA team to lead the charge, but what matters most is that someone own the overall effort and then engages the appropriate IT and business subject matter experts  to develop the information architecture and then govern it. The real trick is to scope the program in increments to be able to deliver near-term benefits in the context of projects that deliver business value while working on the strategic goal. But by no means should an organization treat the whole issue of rationalizing data sources casually in an ad hoc manner. Look for upcoming research from us to provide more details on this issue.

EA's Value To The Core IT Processes

EA's Value To The Core IT Processes

We’ll take the last three questions together as they’re all about tools to support EA:

“EA teams struggle to justify the cost of tools to support them. There is rarely any quantified ROI of investing in EA solutions.  How are they to overcome this?”

“Can you address the role of collaboration tools in EA teams?”

“Is it idealistic or too far out to consider that automating many related aspects of EA through tool integration is possible. For example, from the information architecture viewpoint you structure your data classifications and categories; from a technology viewpoint you capture the maturity of your products (i.e., those strategic ones to re-use, those to contain/retire, etc.); and for solutions architecture you capture business requirements. Is there a way to use the tools associated with one space in the other?”


Most EA teams just use diagramming tools such as Visio either because, up to now, that’s all they really needed or because they could justify neither the cost of the more elaborate EA tool offerings nor the time investment needed to master them and train everyone they’d want to use them. That picture is starting to change as EA teams become more federated and find themselves needing to tie a growing multitude of SMEs into a cohesive EA effort. The trend towards business architecture will also help move this along as a key focus area for this discipline is relating medium-detail-level business architecture components, such as capabilities, to their corresponding IT components, such as services or applications. Analyzing dependencies in complex environments and building detailed strategies will increasingly require a repository, modeling standards, and a variety of models. The gold will be in analyzing the interrelationships between business capabilities and technology’s capabilities, and the ability to look at the layers separately and together will become increasingly important. And even if this kind of analysis can be achieved manually with great effort as a one-off project using simple Office tools, it will be impossible to maintain manual models in complex environments, and the value in the effort will be quickly lost as the info gets out of date. On top of that, as the second question hints at, the growing network of architects will make some sort of collaboration tools a requirement.

However, while I feel confident the need for EA tools is growing dramatically, that doesn’t mean that it will be much easier to justify the investment in one. It’s still difficult to communicate the value of EA efforts to folks who focus intensely on near-term solutions within organizational silos (that is, most people in most organizations). But if the EA function exists, then somebody in a management role in your organization must believe in its value. Start there to explain what you would do with a tool. Be specific. Generalizations about how a tool would be a great asset clearly won’t fly. But the ideal of pinning tool value to a specific ROI may be elusive. You could use the tool to analyze, for example, your application and infrastructure software portfolio and identify all the redundancies, claiming all the cost savings that would result from consolidation as tool ROI. But you could probably do that, albeit with more labor, without a tool, and many consolidation projects don’t get past the drawing board.

So I don’t think that linking to a specific project’s ROI is the way to justify investment in an EA tool. I think the value in an EA tool is strongly related to the value of the EA program, which is both fuzzy and powerful. Fuzzy is bad when you’re trying to get someone to write a check, but EA can provide significant value and an EA tool can enable analysis and visualization in important ways.

Back to starting with your local EA advocate in management – for many your CIO – and being specific about what you’d do with an EA tool. To do that, you have to understand the available tools’ capabilities and think through how you might use them in your EA program. You will have to show specifics about how the tool will either save a significant amount of time and labor, or, better, enable analysis that would otherwise be impossible manually. That means you’ll have to research the tools, find case studies of how they’ve provided value, and determine which features and functions you would make best use of. Then write the story of what great things you would do if you had the right tool, and start pitching. No shortcuts here, I’m afraid.

And about that question about tools to promote architect collaboration – once you’ve created a short list of tools, see if there is a related feature available. If you can get some of that functionality in a package that you can roll out to your network of architects and SMEs, great. But there are probably collaboration tools already in your shop (that you may have helped to standardize) that you can look to  to foster collaboration. Internal blogs, Wikis and Sharepoint sites can be relatively simple things but provide the functionality you need to get architects talking to one another, even across a widely distributed organization. It doesn’t have to be fancy – all you really need is a place to post discussions (with appropriate tagging/search/archiving functionality) and a way to message your architect community in real time.

Good Order-taking Is Not Good Enough

October 19, 2009 Leave a comment

I’m currently dealing with a client whose IT department is pretty good at being an order-taker. But the business folks are dissatisfied. An LOB exec told me “when we told IT we wanted [a particular solution] they should have probed for what the real issues were and then come up with a better solution than what we asked for. They should have pushed back.” I don’t know about you, but I find this remarkable.

For years IT has struggled to be the best possible order-taker. Back in 2006, Forrester defined three archetypes of IT: The Solid Utility, the Trusted  Supplier, and the Partner Player (see  the first figure). These archetypes are progressive: you can’t be a Trusted Supplier without also being

IT Archetypes

IT Archetypes

a Solid Utility, etc. It took a lot of work to be a solid utility by providing cost-effective dial-tone reliability with transparent, constantly declining costs. And then it took a lot of organizational maturity to attain Trusted Supplier status by nailing projects and consistently delivering on-time, on-budget, and to spec. So when we talk about being a Partner Player, being at the proverbial table and helping to move the business forward, it really sounds like IT management nirvana — we’re going beyond technical execution into the strategic realm.

Of course, EA programs can help at each phase (see the next figure). EA can help by defining

EA Enables IT Archetypes

EA Enables IT Archetypes

and governing to the standards and technology strategy that make IT cost-effective to run and support, and by baking these standards into application patterns that take a significant amount of risk out of development projects. And by pursuing business architecture, EA can begin to have the strategic discussions that will lead to being perceived as a Partner Player.

But back to the IT department I mentioned at the beginning of this post. These folks are crying out for architect-led interactions at the brainstorming stage, but their organizational culture and their processes currently prevent the whole “dream with me” stage described by Eric Hendrickson in his comment to a previous post. Making those interactions happen and formalizing them into regular occurrences is the way to nail the alignment problem and move into strategic discussions. But for this organization it’s not a nice-to-have — it’s as big a black eye as failing to provide a sound infrastructure or always being late with projects.

If this is generalizable to the industry at large, then getting to be a Partner Player is no longer an aspiration that would be nice to achieve but a no-big-deal-if-we-don’t-nail-it-this-year sort of thing. Being a Partner Player is  just meeting expectations. It’s just what the business perceives as necessary to utilize technology in a way that will enable them to survive, compete, and excel. And my take on this client so far is that they are a relatively conservative organization, so if their business folks have this expectation of IT, many others do also.

That means the bar has been raised. IT organizations must evaluate themselves and see if they’re headed in this direction soon. If not, it’s time to change something: change your organizational design, change your processes, change your strategy, change whatever you need to change to make this happen. And since I’m an EA guy, I have to say my view is that the EA effort is where to place your bets.

Comments welcome and encouraged, of course. Take another 30 seconds and take this quick poll — how would you characterize your organization?