Policy-based SOA Will Enable Increased Business Value And Agility

[Posted by Randy Heffner]

One of my favorite Forrester survey statistics to quote about SOA is the proportion of service-oriented architecture (SOA) users that see how important SOA can be for changing their business. In our Enterprise And SMB Software Survey, North America And Europe, Q4 2008 (taken after the start of the current economic crisis), 38% of Global 2000 SOA adopters said they are using SOA for strategic business transformation. This is a very high level of business impact — and far more value than was ever credited to object-oriented or component-based development. Why is this important to note? Many think of SOA first as a technology for reuse, like objects and components, and miss the reality that SOA is much more about business design and flexibility. By missing the business perspective on SOA, they miss the fact that SOA is the foundation for a much broader shift in application architecture and its relationship to the design, monitoring, and optimization of business processes.

And this brings us to the importance of policy-based SOA as an area of technology strategy for enterprise architects to pay attention to. Many SOA adopters already use security and management policy with their SOA-based services, and the future allows a much broader impact by applying other types of policy, including business policy, to SOA implementations. Among Forrester’s top 15 technologies, policy-based SOA is the highest in terms of newness and complexity, which means that, although the potential for business flexibility and value is there, it will take longer to understand, plan for, and adopt policy-based SOA than it will take for other top technologies. As a first step, architects should ensure that they understand the concepts so that they can set the right time frame for building toward policy-based SOA as they build platforms and patterns for SOA.

To begin to understand policy-based SOA, consider security and management. Products like SOA appliances, enterprise service busses (ESBs), and SOA and Web services management solutions provide for policy-based that control service execution. You  define a security policy (e.g., “service requests must be accompanied by a WS-Security SAML token to identify the service consumer”) using the SOA product’s administration tool. At runtime, the SOA product intercepts the SOA request, applies the security policy, and either rejects the request (if the policy is not met) or forwards the request to the service for processing. The important point here is that the policy is declared separately from the service, allowing it to change without changing the service itself. In a similar way, policies for production monitoring (e.g., response time and availability) are declared separately and applied at runtime. Some of the benefits of this type of policy separation include:

• The active policy is easily and widely visible. If the policy is buried in the service implementation, the only definitive way to determine the active policy is to look at the code.
• The failure responses are highly configurable. SOA products provide multiple ways to respond to a policy failure, and these can be changed without changing the service.
• Monitoring and auditing are both configurable. SOA products can provide dynamically configured data for auditing service operations and usage.
• Monitoring may include business-level insight. Besides technical operations data, SOA products can extract business data from service requests and responses, thereby enabling business-level monitoring.

These same concepts can be applied to business policies associated with SOA-based services. Examples of such policies include:

• If total expenses are less than $50, route the expense report SOA request to the automated approval service, else route it to the manager approval queue service.
• If the submit order SOA request is from a gold customer, mark it to bypass the credit check.
• If the medical order SOA request is for a medical procedure from category 1, send an audit copy of the request to the medical quality assurance and risk management queue.

By extracting such decisions from the internals of service implementations, we provide the business with ready access for changing and optimizing business processes. But here’s the issue: Without a broad perspective on SOA policy, organizations can implement policy silos for SOA that duplicate tools and infrastructure for each different type of SOA policy. Security policy might be contained in an SOA appliance silo, management policy might be in an SOA management solution silo, business policy might be in an ESB silo. The two biggest problems this creates are 1) it is difficult to get a complete picture of a given SOA service’s production processing, and 2) it duplicates infrastructure and processes for policy authoring, auditing, and life cycle control.

Therefore, Forrester recommends taking a step back to understand the full possibilities, requirements, and business value of policy-based SOA. This will allow architects to craft an incremental and evolutionary strategy for starting small, typically with security or management policy, and growing into the full range of value available with policy-based SOA.

To read more about policy-based SOA, go to the five-part report series that begins with How To Get Started On SOA Policy Management.

Best Practices To Avoid Marginalization

[Posted by Alex Cullen]

 

Architecture teams often spend a significant amount of their time working with or consulting for IT project teams. This is a recognized best practice for ensuring that project teams execute in line with the architecture and for demonstrating that the architecture team provides tangible value, but it is also a double-edged sword. The downside is when IT management perceives that the EA team's primary value is in tactical problem solving. When IT management has this perception, at best, EA's strategic contribution is devalued, or teams are so busy on tactical issues that they don't have time to be strategic. At worst, the EA team is disbanded and architects are instead embedded in technology areas "to get closer to the delivery teams." We've all seen this; approximately 45% of firms don't have any centralized architecture function because they've chosen this route. EA programs start with good intentions but ultimately are marginalized.

This past month, we've published a number of reports that address how to avoid marginalization. In "Case Study: WestJet Creates Clarity With Its Architecture Services Catalog," we profile how one EA team as an outcome of an ITIL service catalog exercise was better able to communicate how it could help stakeholders with their highest-impact issues. At a broader level, in Jeff Scott's report "Successful EA Programs Integrate Specific Value Levers And Accelerators," we describe the full range of techniques EA teams should use to avoid marginalization, such as making sure strategies are aligned and focusing on standards that provide benefit.

 

I'd like to draw your attention to a number of upcoming reports and events. First, we are expanding our research base in two key architecture domains. Gene Leganza will be publishing a series of reports on best practices for focusing information architecture on where the organization sees the most value. Galen Schreck will be describing how your infrastructure architecture will evolve and how you can assess where you are and where you need to plan on changes. Lastly, I'd like to encourage you to:

Save the date!

Forrester's Enterprise Architecture Forum 2010: Leveraging Architecture For Business Impact

We'll have keynotes describing how architecture is being used in business transformation, the future of architecture standards, and how to develop technology strategies for business change. And we'll have sessions that drill into business and information architecture, technology futures, and EA effectiveness.

San Diego, Calif.

February 11-12, 2010

London, UK.

March 2-3, 2010

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.

Is Your Organization Planning For (Or Doing) Cloud Computing? We Want To Talk To You!

[Posted by Randy Heffner]

Forrester Principal Analyst, Randy Heffner is currently conducting research on how enterprise architects should incorporate cloud computing into their organizations’ IT strategies and architectures. He is looking for enterprise architects to interview — architects that have experience with evaluating Cloud offerings, if not actually using them. In the research, Randy is considering three broad categories of cloud computing offerings: Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS).

Because the term “cloud computing” refers to quite diverse types of services and products, architects need to analyze and build multiple cloud strategies. Although there are potentially strong benefits, the costs, risks, and best usage scenarios are not necessarily clear. At minimum, adopting cloud-based offerings requires changes in IT’s planning, cost management, solution design, and production operations. To predict and manage the impact, architects must examine cloud options to determine the impact on their architecture plans and strategies. This report will analyze how interviewees see cloud computing’s effect on their organization’s:

• Architecture planning

• Solution delivery architectures and projects

• IT operations

• IT management practices

The final research report will be available exclusively for the members of the Enterprise Architecture (EA) Council as part of Forrester Leadership Boards. The EA Council consists of over 200 members who are the senior most individual responsible for Enterprise Architecture of primarily $1B+ companies across a wide variety of industries.  

Anyone who we interview will also receive a complimentary copy of the research report.

Randy is looking for candidates to interview who answer “Yes” to the following questions:

1.       Are you an enterprise architect who has been involved in evaluating, selecting, and/or implementing one or more cloud-based offerings?

2.       From your planning and (if applicable) use of cloud-based offerings, can you share examples of pros, cons, planning requirements, pitfalls, best practices, and/or other experiences?

Since cloud-based offerings are relatively new and used by the minority of organizations, Randy is interested in talking both to those (a) that have experience using them and (b) that have put significant effort into analysis and planning for them, whether or not they have actually used them. 

If you answered “Yes” to both of the above questions and are interested in participating, please get in touch with either Mimi An or Katie Smillie. 

Identifying The Technologies That Will Matter

[Posted by Alex Cullen]

CIOs want to know what new technologies they should watch for their firm’s possible use.  They need to know when they should make an investment of time to learn a technology, and educate their business on its potential – or be prepared to answer their questions.  They want to time their own adoption - for example, with cloud-based services, they want to maximize benefits, avoid the bleeding edge, and smoothly fold it in with their plans.  CIOs need a ‘technology watch list' when they have a central architecture teams, they delegate creating this list to that team.  These teams tap their sources - and one source the architecture teams tap to scan the long list of technologies is Forrester.

 

At Forrester, we are challenged to identify the top technologies, too.  Our problem is a bit different from our clients – we follow so many technologies, hear from so vendors and thought leaders, and of course every analyst will have their own network and assessment.  To sort through everything that could be on a watch list and pick the ones which CIOs should watch, we involve many analysts and use a simple set of criteria:

 

• It’s got to matter within three years if it’s going to be worth watching.  Of course we all know there are trends in computing architectures or neural networks or others that might have a big impact – but your average business or even aggressive adopters can’t do anything today with these long lead-time technologies.  You might as well save your bandwidth and watch the ones that matter within a reasonable planning & adoption cycle.

 

• It’s got to have a significant impact on business, or on the business of IT.  Business impact is simply ‘can the business do something that it can’t easily do today?’.  Can it better understand customer behavior? Can it drive down the cost of internal processes? IT impact can be both positive or negative:  Does it impact cost positively or negatively?  Does it impact quality positively or negatively? Does it impact IT’s ability to serve business positively or negatively?  Like George Colony, Forrester’s CEO, observed: “Web 2.0 has forever changed the relationship between your company and your customer.” If a technology trend like Web 2.0 will have significant impact, shouldn’t you be looking at it? If it doesn’t have significant impact, why get excited about it? 

 

• It has to be new or significantly different from what’s available today.  There are a lot of impactful technologies in use today that will be more impactful three years from now – but they will be basically the same technologies that are in use today.  CIOs’ organizations are already familiar with them and only need to ‘keep up to speed.’ But others, like business rules engines, will be essentially completely new, and IT will need to ramp up on them, understanding potential benefits and risks before they make their adoption decisions. For existing technologies – it’s ‘business as usual,’ but for new technologies, you have to pick which ones you will ramp up on. 

 

• You need to understand how complex implementation might be.  Complexity drives when you need to start looking.  A technology that could change business strategy will be very complex to adopt – involving multiple stakeholders, and impacting multiple IT and business areas.  It will take a long time to plan so, if the business impact is worth it, you want to start early.  Other impactful technology might be a simple case of acquiring and using. You don’t need a lot of time to plan for it. 

 

Why is collaboration across Forrester analysts so important?  Simply put, making a prediction which our clients can trust takes more than just one person’s opinion.  With lots of input from analysts across Forrester’s technology coverage, and with an equal amount of vetting by these same analysts, we will produce a more trustworthy prediction of which technologies will matter.  If the consensus of analysts is that real-time, process-centric business intelligence will have a bigger impact than model-driven software development, the chances are it will. 

 

Which technologies should EA’s watch?  It’s not a matter of ‘cool technologies’ – although they may be fun, or ‘hot technologies’ – although they may be hot for a reason.  It’s really about which ones will matter because of their impact, their ‘newness’ and the potential complexity they bring with them, within a timeframe organizations can plan around.

 

Over the coming months, Forrester analysts will take to our blogs and take a closer look at the 15 technologies we selected, adding what they see on the immediate horizon for 2010.   

 

Which technologies are on your list? 

State of Enterprise Architecture Survey

Forrester's annual State of Enterprise Architecture survey needs more respondents!  Help Forrester benchmark EA's progress by answering a set of 25 questions on how architecture is practiced in large enterprises.  At the end of the survey, we'll ask you if you wish to attend a complimentary webinar on the results.  All participants will receive an Excel workbook of the results.  Thank you for your participation.

Take the survey

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!

Will Business Architecture Initiatives Put A Permanent End To Business-IT Alignment Problems?

[Posted by Gene Leganza]

An early 2009 Forrester interview with the CIO of a retail firm produced a great quote: “Our business execs have two views of IT: a big budget blob or their BlackBerry.” Now, maybe those retail business execs think of IT as a strategic budget blob, but it’s more likely that’s a shop with alignment issues. If that CIO’s business execs don’t see technology as enabling anything more than mobile email, then they really don’t get the power of technology and they’re not going to see the value in the IT department.

But alignment issues are not limited to shops where business execs don’t see value in technology. The whole IT-to-BT transition is about how the business is enthusiastically embracing technology – they’re just not bothering to go through the IT department to find it, deploy it, or use it. Today’s alignment problem is more about the gap between the business’s valuation of technology’s potential and their valuation of the IT department’s ability to deliver on that potential.

 

Enterprise architecture (EA) has always had the capability to bridge that gap. Now, I certainly can’t claim that all or even most organizations that implemented an EA practice have solved all their alignment problems. But the simplest explanation of how an EA program is supposed to work would stand in for a perfect formula for aligning any enterprise: Map out the current and future states of your organization’s business, information, application, and infrastructure architectures, create the detailed roadmaps that spell out how to go from where you are to that desired future state and bingo! Business execs would know exactly what IT was up to and why they were doing it. They’d be cheering and carrying their IT and EA pals on their shoulders on the way to the next stockholders’ meeting.

 

What? Hasn’t happened to you yet? What could possibly be wrong? Perhaps it’s that most EA programs haven’t exactly executed the classic formula. Perhaps EA has focused almost entirely on technology and applications and the business has perceived EA – if it has indeed been perceptible at all to the business – as just another thing IT was doing that didn’t matter much to them. Maybe until very recently, for most organizations the business architecture piece has been missing in action (and let’s talk about information architecture another day). No business architecture, no relevance to the business community.

But all that is changing. Suddenly it seems business architecture is the hottest topic in EA circles. When I spoke to clients at Forrester’s IT Forum in May and our EA Forum back in February, business architecture was practically all anyone in the EA role was talking about, whether their EA practice was 10 years or 10 days old. A variety of forces have conspired to make technology-only architecture initiatives seem only marginally worth pursuing. These forces include a relentless drive for value – which implies an accompanying drive for transparency – and a continuing breakdown of the insularity of the IT organization.

But for whatever the reasons, business architecture programs are taking off, and I think that wherever they get traction they will finally put an end to business-IT alignment problems for good.  Why? Because whatever the form of the business architecture program, business and IT will interact regularly and work together on addressing business problems and attaining business goals. Business execs will become invested in the connection between implementing the to-be business architecture and the rest of the enterprise architecture domains, at least in terms of the dependencies. And of course, IT will recognize the opportunity to communicate meaningfully with their business partners to ensure complete transparency and to relate all IT resource expenditures to business goals.

But wait a minute, back up – did he say “whatever the form of the business architecture program”? Isn’t there a cookbook of best practices that everyone can follow? The fact is that best practices are evolving, but at this point there are many approaches to business architecture initiatives. Jeff Scott and I have written a series of case studies on business-focused architecture to showcase the different approaches and provide a context for the value they are producing. We also presented a webinar on August 5 that discussed three of the case studies briefly and presented Forrester’s approach to starting business architecture initiatives. We touched on a number of issues, either through the planned agenda or the lively Q&A, including the role of business architecture in the context of the larger EA program and recommendations for the right business architecture artifacts. Regarding the latter point, I discussed a capability map from one of the case studies (see below) and Jeff talked about this type of representation as the “Rosetta stone” for business-IT alignment, which got some traction in the Twittersphere.

 

In the concurrent chat session embedded in the webinar, we covered a number of very interesting questions, but, given the circumstances, we really just touched on them lightly. Some of these issues clearly warrant further analysis and discussion, such as:

How would we reconcile the two opposing views presented in the case studies, where IT management was intimately involved with business architecture discussions in one case and locked out of the room in another in order to avoid biasing the discussion with current system constraints?
What are the best tools for creating business architecture artifacts? How important are the more elaborate EA tools?

How might capability maps work in organizations that have advanced ITIL/ITSM practices? Or that have successful APM/PPM efforts? Wouldn’t this form of business architecture artifact work well in analyzing IT as a business?

 

I invite anyone who attended the session or access the archived version to post comments here on the above questions – or any related issues for that matter. There are plenty of best practices to be surfaced as this area is still evolving.

There is actually a lot you can accomplish with business architecture, from finding efficiencies to launching new business capabilities to transforming the business. Important as it is, attaining business/IT alignment, the subject of the webinar and this blog post, can seem like just a beneficial side effect when you consider the high-impact possibilities.

Understanding EA's Value

[Posted by Jeff Scott]

Creating and demonstrating value continues to be a critical issue for many EA teams. Forrester believes that architects can have greater impact by tightly tying their activities to value levers their organizations care about and demonstrating how EA supports IT goals. Why does value continue to be a top-of-mind issue for EAs? Why don’t organizations recognize and appreciate EA’s value? Forrester is conducting a research initiative to assess the state of the market and identify best practices successful EA teams use to create and demonstrate value.

We are asking our blog readers to contribute to this client-driven research by taking a 16 question survey. To thank you for your time completing this survey, we'll provide you with the survey results so you can see how your responses compare with others, as well as the chance to participate in a 30 min teleconference with Forrester analysts who will tell you 'what it means.’

Click here to take the survey.

Thank you in advance.

 

Software AG Announces IDS Scheer Acquisition: Is The Tail Wagging The Dog?

By Clay Richardson, Ken Vollmer, and Connie Moore

Only two years after acquiring webMethods, Software AG shakes up the BPM world once again with its announcement to acquire leading process modeling vendor IDS Scheer.  Since the webMethods acquisition, Software AG has continued to push the envelope on combining solid human-centric and integration-centric capabilities under a single vendor roof.  With the IDS Scheer acquisition, Software AG is sending an indisputable and clear message to the market:  "We are a major BPM player, hear us roar!"  Or should it be, "hear us bark?"

In many ways IDS Scheer has more brand cachet in business process improvement circlesthan Software AG, leading us to wonder: Is the tail wagging the dog on this deal?  Is Software AG buying IDS Scheer, or is IDS Scheer really buying Software AG?  The truth is that Software AG is buying a global brand that has the potential to completely remake Software AG into a process improvement powerhouse.

On the surface, Software AG has positioned this acquisition as a vehicle for opening up new global markets they are trying to further penetrate - such as Latin America and Asia Pacific.  Specifically, they expect to expand their consulting footprints in these markets in order to support increased license sales.  No doubt, Latin America is poised for growth and Software AG has timed this acquisition to capitalize on projected growth in Brazil and Venezuela, which continue to see single and double digit increases in technology spend.

Looking beyond surface observations, we see three key reasons why this acquisition makes sense and why it will play well in the market place:

• The Need For Execution - IDS Scheer needed an execution engine in order to remain relevant and credible in the eyes of process pros responsible for expanding enterprise BPM initiatives.  Although the majority of IDS Scheer's customers use Aris for SAP implementations, many of these customers are looking for simpler alternatives to SAP for process execution.  Looking forward, Aris customers could build out their process models and decide whether to deploy to SAP or webMethods (or another BPM environment) - depending on the process' complexity and reliance on SAP data and applications.

• The Need For Business Empowerment - Since the webMethods acquisition, Software AG has struggled to break away from its "integration-centric" roots.  Ask the average CIO about webMethods and she's likely to say, "Yeah, they really do a great job with EAI."  However, the reality is that over the last three years webMethods has completely revamped the platform to truly support human-centric processes while maintaining key integration-centric components.  With the IDS Scheer acquisition, Software AG doubles down on its commitment to empower the business to align process initiatives with key strategic goals and objectives.  

• A Seat In The C-Suite - Ultimately, this acquisition will increase Software AG's stature and profile within large enterprises - moving webMethods from a technology component in the IT stack to a key ingredient in their customer's process strategy.  Keep in mind that IDS Scheer is well regarded as a platform for supporting large BPM Center of Excellence efforts, which typically enjoy healthy support from CEO's and COO's.  

So, what's it mean?

• Aris customers shouldn't sweat - Aris customers should breathe easy, since Software AG has agreed to treat Aris as a separate entity, with its own roadmap and strategic direction.  This was a smart move by Software AG, in order to not rock the boat with key Aris partners SAP and Oracle.  

• Watch for SAP's response - Middleware consolidation is accelerating.  The acquisition of IDS leaves SAP with no viable options to shore up the NetWeaver stack other than to look at Informatica or Software AG, though it’s been rumored for some time that SOA software was on their target list.  Rumors have also been rampant about a potential SAP acquisition of Software AG.  In addition to regaining control of the IDS Scheer modeling capability, there are additional factors that could make such a move beneficial for SAP.  For example, replacing NetWeaver XI/PI with webMethods would solve a persistent problem of interfacing SAP applications with the outside world.  It would also provide native EDI capability that SAP customers must currently obtain via SAP partnerships with CrossGate and Seeburger.  

• M&A activity will continue in the BPM space - In the current economic environment, many smaller BPM vendors are running out of runway to launch their companies to the next level.  These vendors are beginning to face the reality of acquisition or failure, and larger stack vendors (with cash) realize that now is the time to go bargain hunting for struggling vendors.  We expect M&A activity to continue in the BPM space; however, it will not be in the most obvious pairings - as signaled by the Software AG and IDS Scheer situation.

Our Point Of View

Overall, Forrester expects this to be a successful deal for both Software AG and IDS Scheer customers, with minimal disruption and adverse impact on combined customer portfolios.  Software AG customers will benefit from an extensive process analysis modeling platform and professional services organization that can support multi-million dollar, multi-year BPM initiatives; and IDS Scheer customers will benefit from a robust execution engine that can support human-centric and integration-centric business processes.

The big loser is SAP - and to a lesser extent Oracle.  Both use IDS Scheer to augment their internal process modeling capability.  Now they will have to rely on a competitor for this functionality.

In the end, it really doesn't matter if the tail is wagging the dog - all that matters is whether the dog's bite matches its bark.  And in this case, the combined Software AG / IDS Scheer offering seems to be a good match.

Sound Off

We want to hear from you.  Let us know what you think of the IDS Scheer acquisition.  Do you think this acquisition will have a net positive impact on the BPM market?  Do you think the combined technology portfolios of Software AG and IDS Scheer are complimentary and will improve their customers’ process improvement efforts?  How do you think SAP will respond?  Post your thoughts in the comment section or feel free to shoot us a quick e-mail at crichardson@forrester.com or kvollmer@forrester.com.