Questions From The Next-Gen EA Teleconference On October 23, 2009

[Posted by Gene Leganza]

Questions From The Next-Gen EA Teleconference On October 23, 2009

Jeff Scott and I presented a teleconference entitled “Next-Generation Enterprise Architecture” last week. 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 kick 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?”

Response:

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 managers 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.

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?”

Response:

Now that’s a big question and it’s generally the main subject of 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.

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?”

Response:

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 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.

Babies, Bath Water, And Enterprise Architecture Maturity Models

[Posted by Gene Leganza]

Recently I took a look at an EA-maturity-model-cum-roadmap from Leo de Sousa, Manager of Business Application Services and Enterprise Architecture at the British Columbia Institute of Technology (click to read Leo’s blog on EA CMM). To my surprise, I liked it. Why was I surprised?

I have never liked EA maturity models. Yes, tracking progress is important. And yes, there should be a consensus about what characterizes a mature EA practice. But I don’t like how they would ostensibly be used to compare one enterprise with another, a la benchmarks. Perhaps I was soured on them by seeing them used as a governance technique in US federal agencies.

The Office of Management and Budget (OMB) required agencies to assess themselves against a standardized maturity model, with progressive hurdles in successive years. Federal agencies, accustomed as they are to all sorts of oversight and compliance mandates, know how to pass compliance audits. Did you ever wonder how (then) Popkin System Architect got so popular  in the federal government? An EA tool was required to demonstrate a certain level of EA maturity and System Architect was the lowest-cost offering at the time (I’m sure there are other reasons as well). Behavior was around letter-of-the-law compliance, and it seldom catalyzed getting with the spirit. Even when Dick Burk at OMB introduced a clever workaround in a second version of the model — you could leapfrog to a level 4 if you showed actual business benefits, regardless of what other checklist items you missed — agencies simply marched through the maturity level checklists getting the requisite items done. The scores were good, but in my opinion they overstated the degree to which EA was ingrained in the culture of the agencies.

And then there’s the notion of a single number representing an enterprise. In most reasonably large organizations, there is some degree of federation of the EA effort. Some business units might have very advanced practices, while others have virtually none, and the enterprise-wide practice may have an entirely different agenda. What does one do, rate all units and average the number? That would be a pretty meaningless metric.

Source: Leo de Sousa, Manager, Business Application Services and Enterprise Architecture, British Columbia Institute of Technology

So, I’m afraid because  of all this I threw the proverbial baby out with the bath water regarding EA maturity models. But I like Leo’s. He took some fairly standard criteria and modified them to fit his organizational goals and processes. They still resemble other CMMI-like level criteria, so his 3 would be similar to someone else’s 3, but that’s not the main point. The point is to create a roadmap for where he wants his EA practice to go, and then rate and report actual against plan. This approach is about creating a tailored roadmap to consciously mature your EA practice; it is not about scoring maturity of implemented architectures.

No big deal, you say? I tweeted about this and a couple of wise EA folks who usually respond to my tweets essentially said “of course, you have to make it your own, what else would you do?” making me wonder if I’ve been missing the boat all along.  But I don’t think this is a prevalent attitude about EA maturity models. I think the general idea is to rate one’s org against where it ought to be, by some industry-standard scale. I don’t find that worth much. I think an organization should understand where they are and where they want to be, figure out how to get there, and track their progress. If someone else’s model of how EA can improve your org helps you describe your goal or your path, great. But generic doesn’t work — for any generic goal statement, you must edit it into terms specific to your enterprise. And don’t set any goals without including the statement “as measured by ___.” You can use the Goal-Question-Metric technique for filling in the blank, but that’s a topic for another day.

To really manage your EA agenda, I’d recommend taking the maturity model as a roadmap a step further and also populate it with goals that don’t fit the standard CMMI scale language.  For example, if you have an incipient information architecture or business architecture practice, place goals and milestones related to expanding and formalizing those efforts on the roadmap. I’ve been interviewing people about their information architecture initiatives and working with Forrester analyst Jeff Scott on approaches to business architecture that can be broken down into a cookbook-like  sequence, so watch this space for more on phased approaches to these aspects of architecture initiatives.

How do you all measure EA progress in your shops? Do you use a maturity model? And/or have you created concrete custom goals with associated metrics and measure against them? Take the quick poll on my personal blog and we’ll all get to see!

Observations From Day 2 Of Forrester’s EA Forum

[Posted by Gene Leganza]

OK, so I didn’t take notes today on what tidbits I might blog about; I think my brain has reached the saturation point. These forums are intense for both the audience and the analysts. Still a great buzz here today, though, it’s just about a lot of very enthusiastic enterprise architects. Not that that is anything new; enterprise architects are a very engaged, very intellectually curious crowd, always at the ready to explore ideas. I think we managed to tap into some really key issues for enterprise architects in our keynotes and track sessions this year. John Rymer and Dave West’s keynote on Lean software generated a ton of interest – we had so many questions that we’re going to have to find a way to publish a response to them all (see Forrester’s web site or the App Dev team’s blog in the near future). And then our debate between Dave West as the (evil) Champion of Agile Development versus myself as the Champion of Architecture seriously struck a chord. Sure, we hammed it up for entertainment value, but people are seeing exactly this debate going on in their environments. Or rather, they’re seeing the conflict and it hasn’t even risen to the level of a debate yet in some cases. Agile methods fulfill a real need in the interaction between business and app development, but we’re in danger of throwing the proverbial baby out with the bathwater by addressing responsiveness but foregoing adherence to a meaningful set of architecture platform standards. We think it’s imperative – and completely attainable – to achieve the goals of Agile while still achieving the goals of enterprise architecture. We must! It’s what the business needs, and it will require compromise by both Agile zealots and EA zealots.

We’ve been talking a lot about addressing business needs in the last 2 days, and in my conversations with clients it seems that an approach that blows away classic knee-jerk EA attitudes and ideas about what EA is supposed to be is becoming more commonplace. This sort of thing used to be the viewpoint of rare individuals who really got it. Now we’re seeing more EA leaders making no assumptions about what EA should be – they’re just making sure what it is and what it does has a clear positive impact on the business. In some cases this is resulting from individuals without EA backgrounds being put in charge of EA. These folks come in with no assumptions. They do some research into what EA is all about, and they are quite happy to ignore the stuff that doesn’t relate to their needs and just pick up on the stuff that will work for them. The approach is pragmatic and fit-to-purpose. The EA part comes from looking enterprise-wide and strategically into the future beyond the more typical short-term goals. These folks don’t have room for idealists or zealots, they’re just trying to create a meaningful and relevant strategy. I think this is because 1) The old model didn’t work: describe it how you might, it basically wound up sounding like architecture for architecture’s sake to all the non-architects you were trying to influence; and 2) we don’t yet have a very prescriptive cookbook on how to do enterprise architecture in the “new” way that includes a major focus on business architecture. Without the availability of step-by-step guidance on how to “do EA right,”  EA leaders are forced to wipe the slate clean and ask really basic questions like “what does the business need from EA at this point in time?” and “what are the most important things we can do this year to show value?” This is a good thing and will result in a new set of best practices.

We took a stand at this EA Forum. We said a shift has to happen now, from the EA program of the past, which was really about technology strategy, to the EA program of the future, which is about the business strategy. Some folks have always thought that EA was about more than the technology strategy, of course, and there probably has been a steady increase of this sort of thinking, but it seems to have reached a tipping point where it feels like a discrete shift in thinking across the industry at large. It doesn’t feel gradual. What it feels like from the feedback I’ve gotten so far about our EA Forum this year is that enterprise architects are more than ready to get behind this shift in direction. There’s a buzz in the air about a change needed and the excitement that comes with new possibilities. One client said to me “this is great – Forrester is helping to change the industry direction on how to approach enterprise architecture.” Well, perhaps our trumpeting these sort of ideas will help increase to momentum of change, but it’s already there – we’re just recognizing it and trying to figure out how to help it along. I think it’s our role-based strategy at work – we’re just trying harder to get inside enterprise architects’ heads and then working on figuring out what kind of assistance a research and advisory company can provide once we understand the situation. At an event like this, it seemed appropriate to run these ideas up the flagpole. The result? We’re seeing a lot of saluting out there!

Observations And Thoughts From Day 1 Of Our EA Forum

[Posted by Gene Leganza]

There’s quite a buzz here at Forrester’s EA Forum. There is just a lot going on in EA circles these days, and the horrible state of the economy can’t seem to suppress it. The general notion that EA practices should directly support the business is really taking hold. While this has always ostensibly been a key aspect of EA, most organizations really focused their EA practices on their technology strategies. I’m getting a lot of positive feedback that a primary focus on business value is the only way to keep EA practices relevant; and these days, not relevant is not tolerated.

There were great questions from a very engaged audience for each of the keynote sessions. For Jeff Scott’s keynote about the mandate to engage in business architecture, there was no resistance to making that quantum leap, just questions about how to proceed – lots of questions. The audience ate up Jeanne Ross’ terrific keynote about architecting agility, and probably could have gone on all morning pumping her about the best practices her research has uncovered regarding developing the organizational maturity required to truly achieve global agility. Hub Vandervoort’s keynote reminded us all that technology is pivotal in forging advanced business functionality but Hub was still intensely focused on the vision for the desired state of business capabilities. He showed us how the assumptions of just a few years ago break down under the load of current-day and near-term business requirements, and how continued technology-based innovation was the only way forward.

There was just a ton going in one jam-packed day. Probably my best experience of the day was when a client at a one-on-one session at 3pm told me that he had come to the forum with a whole list of questions he hoped to get answers to before he left, and he had already gotten all the answers he was looking for at that point.

In another one-on-one, a client said that he was trying to hire business architects, and he just can't find them. He had been hoping that one bright spot in the dark cloud that is the economy would be that there would be a lot of great talent on the street. But it seems that there is nowhere near a consensus about what business architects are, what skills they need, what their background should look like. It’s a different problem from trying to hire an information architect; we know what we need from a great information architect, they’re just extremely rare, and the ones that are out there are probably making a ton of money as consultants. But with business architects, you can’t find them to hire if there isn’t a consensus about exactly what they are.

I’m also seeing a theme that has been around for awhile starting to approach critical mass. This is about the term “enterprise architecture.” In organizations that have failed EA efforts in their history, it’s a name that connotes esoteric terminology and abstractions that carry no practical value. Even in organizations with no such failures in their history, it’s off-putting as a label. At the FLB dinner with the EA Council Monday night, I suggested we just call it “planning,” and a council member shot back that it had better be “planning and governance” if you really want to get to the meat. Jeff Scott’s answer to a question about the “elevator pitch” for explaining EA to a CxO, and Jeanne Ross’ answer to a question about meaningful EA metrics at the EA Council lunch also related to this language issue. Jeff responded that you shouldn’t try to explain what EA is to a CxO in an elevator pitch, and Jeanne said (I’m grossly paraphrasing) that there weren’t good pure EA metrics – the measures are in the business success. The value is in the contribution to the business, and talking about EA doesn’t really do anybody any good. No question that the function is important, even critical; it’s just that any attempt to talk about architecture to non-architects inevitably leads to abstractions that business people just aren’t interested in relating to – it’s not their world and you can’t make them care about it. They do like it, however, when you solve their problems and help them reach their goals.

Enterprise Architecture Forum

[Posted by Gene Leganza]

Welcome to the Forrester Enterprise Architecture blog. Keep this site bookmarked as our Forrester EA analysts update this blog on topics that they find interesting, controversial, or just worthy of discussion.

Here’s some big news from the EA team:

We are holding our second annual Enterprise Architecture Forum in Miami, Florida on February 10-11 and our EMEA Enterprise Architecture Forum in London, UK on February 26-27. The forum’s focus is on Elevating Architecture. Why elevate architecture?

Businesses have become digital, and waves of SOA and BPM adoption require enterprise architecture to move closer to the business. Enterprise Architecture professionals must elevate their architecture practices out of the technology trenches, and identify the technologies that will elevate your business' capabilities to the next level of productivity and innovation.

Forrester's Enterprise Architecture Forum 2009 will examine the challenges facing your role and present pragmatic insights and strategies based on data-driven research, surveys, and vendor evaluations featured in Forrester Wave™ reports.

Here are some key takeaways for the event:

• Learn how business architecture can evolve your EA program.
• Examine how an enterprise integration strategy can lower your costs.
• Hear about Web architecture for blazing fast Web site performance.
• See how next-generation information architecture will include SOA and semantic technology.
• Evaluate your strategy for OSGi app servers and lightweight or "lean" containers.
• Learn why and how to build interoperability and federation into your SOA platform strategy.
• Hear effective practices for global enterprise architecture.
• Discuss whether open source software can really save your enterprise money.
• Determine SharePoint's role in your future — is it a problem or an opportunity?
• Understand how to integrate SOA policy into your SOA strategy.
• The entire EA team will be presenting and hobnobbing with our guests. We hope to see and hear from you at the event. To learn more click here (http://www.forrester.com/events).