Application Platform Strategies Blog

Who Owns Your BPM Strategy?

Blogger: JP Morgenthal

When I ask customers who in the organization is responsible for leading their organization's BPM initiative, the answer is often IT.  There are many reasons for this response, but the main reason is that a large number of organizations focus on BPM from a tools perspective.

The correct answer to the question posed in the title is there is no correct answer; it's different for each organization.  However, all to often, the requirement to modify, build  or buy systems in response to business process improvement, ingrains IT in way that limits the business from fully owning the aspects of BPM that need to be governed by the business.

This is a thorny issue that I am hoping I will have time to address more fully in an upcoming report, but just thought I'd jog down a quick blog entry that discusses ownership roles within my five-step plan for BPM, which are: 1) baseline, 2) document, 3) analyze, 4) model, and 5) implement.  Within this five step plan there's a set of shared responsibilities across IT and business, including tool selection.  Indeed, there's different tools that will be used at each one of these steps and one vendor may not be the right supplier for each step.

BPM success is predicated on the fact that organizations recognize that the business process is itself a business object.  It is not a facet of the business that is managed independently, but is a coordinated effort of people and machines.  Moreover, the two most important aspect of BPM to remember are: a) The most straightforward and simple approach is often the most effective and b) sometimes the current process, while awkward and inefficient, may be the best approach for the time being. 

Hence, it is important for those engaging in a BPM initiative to remember, the tools are not the focus of the effort, but a means to an end.  Treat the business process as an independent entity that requires the support of many business departments and work as a cross-functional team to ensure that the right expectations for the initiative are set and understood.  Following these very basic suggestions can mean the difference between BPM success or failure.

SOA doesn't need to be expensive

Blogger: Anne Thomas Manes

It's a common misconception that SOA is expensive. Many organizations believe that they need to acquire a boat-load of new products and technologies to get started with SOA. First on the list of product acquisitions is an ESB, followed by registries, repositories, and security appliances. In these belt-tightening times, many SOA initiatives will be challenged to raise the funding required to acquire these products. So what's a team to do? Pack up and wait for better times? Or make do with what you have?

In truth (and much to the vendors' dismay), you don't need a bunch of new products to do SOA. SOA is about the way you design your solutions -- not about the technology you use to build them. An ESB is a "nice to have", but it's not a prerequisite. Pretty much all programming environments (Java, .NET, Ruby, Groovy, PHP, JavaScript, COBOL, CICS, etc) now include native support for building services -- both method- or document-oriented services built with SOAP and WSDL and RESTful services built with HTTP. You can also build document-oriented services using your favorite message-oriented middleware product (although MOM protocols will limit your reach and interoperability options). (I described the differences among the three types of services here. And see here and here for some great references on RESTful services.)

The only new product that an organization should really budget for is a management solution -- one that supports administration, monitoring, security, and mediation of service interactions (e.g., AmberPoint, Progress Actional, SOA Software Service Manager. Many platform vendors also provide management solutions--sometimes reselling AmberPoint [Oracle and Tibco]).

For organizations that need an ESB, consider open source solutions. Mike Kavis posted a nice summary of open source SOA stacks here. David Linthicum has also been extolling the benefits of an open source SOA product strategy here. Both Mike and Dave point out that the open source solutions tend to be easier to use and more cohesively integrated than the big vendor alternatives. Unfortunately, none of the open source solutions provides a comprehensive management solution yet.

The leading open source projects have commercial backers that provide support, education, and consulting services. For more information about open source (subscribers only), see the following documents:

• Open Source Management: Who Owns That Software?
• Open Source Software: Risks and Rewards
• Assessing Open Source Software Projects 

Building Social Capital: the secret to SOA success

Blogger: Richard Watson

I’ve followed my own advice this week and stepped out of my comfort zone. This week’s Burton Group Inflection Point podcast features my foray into socio-organizationomics to discuss social capital as the secret sauce in SOA success stories. Here's the direct link to the audio. All InflectionPoint podcasts are also available on iTunes.

Our much discussed SOA contextual research study earlier in the year involved dozens of service-oriented architecture (SOA) initiative leaders. The goal was to uncover in-depth data on SOA roadmap dynamics and success factors. This contextual research study and the hundred of discussions we’ve had with our clients over 5 years, confirms our position – a position now resonating widely - that the greatest challenges to SOA success are cultural and organizational, rather than technical.

If you’ve listened to the podcast, here’s a list of complementary references you may find valuable:

• Robert D. Putnam. Bowling Alone: The Collapse and Revival of American Community. New York, New York: Simon & Schuster, 2001.  Putnam discusses social capital in the context of community and political participation.  A seminal and important book.

• Todd Biske. SOA Governance. Birmingham & Mumbai: Packt, 2008.  Todd is spot on in focusing on the team interactions in (fictional enterprise) Advasco’s SOA Centre of Excellence.

• Joe McKendrick. "The beatings will continue until SOA governance improves". Service Oriented Blog. Joe on the failure of getting things done in a command-and-conquer environment.

• For more information on adopting an agile development process, the (Burton Group subscription needed) Application Platform Strategies overview “Agile Software Development: Not for Lightweights is a great introduction.

• My recently published update to our Methodologies and Best Practices document (Burton Group subscription needed) Building the Business Case for Service Oriented Architecture Investment, which refreshes our recommendations and insights for surviving the SOA business-case process.

If you have your own social capital stories, I’d be really interested to continue the discussion in the comments area.

By the way, that comment about getting out of my comfort zone was just an old attention grabbing trick. As Enterprise architects, we need to be finely attuned to the social and organizational aspects of applying IT solutions in a business context, as Mike Rollings reminds us in (free research report) Enterprise Architecture is More than Engineering.

Websphere 7 & OSGi

Blogger: Kirk Knoernschild

I recently spoke to Tim Francis, IBM Distinguished Engineer, and Walt Noffsinger, product manager for Websphere Application Server (WAS), about WAS 7, which was released in October. WAS 7 has a few significant new features, and Walt pointed out that enterprise customers are especially excited about three of them - flexible management options, business level applications, and runtime provisioning based on OSGi.

While the first two are rightfully cool, it's the latter where I want to focus. Few are aware that WAS 6.1 was redesigned and packaged as OSGi bundles. But the capabilities of the OSGi Service Platform were not exposed to the enterprise developer. And in fact, WAS 6.1 didn't take advantage of the dynamic capabilities of OSGi. Instead it was just laying the foundation for what was to come in WAS 7.

WAS 7 improves upon the 6.1 implementation in a key way. Whereas WAS 6.1 was packaged as OSGi bundles, WAS 7 leverages this capability through dynamic provisioning of only the capabilities that are needed. So if an EJB container isn't needed, the EJB Container bundle isn't started. This reduces startup time for applications and also reduces their memory footprint. While those are real advantages, that's where the advantages of OSGi stop in WAS 7.

Tim mentioned that the WAS team has always taken backward compatibility very seriously, and that's evident with WAS 7 still supporting J2EE 1.2. And to ensure that compatibility, more complete bundle lifecycle capabilities will have to wait on the OSGi Enterprise Expert Group, of which IBM is a participant. That includes exposing the benefits of OSGi to the enterprise developer, who are still left dealing with the Java EE deployment model along with any proprietary goodies offered by the container. The dream of a dynamically adaptable application platform, and developers realizing the advantages of OSGi, are starting to arrive. Hopefully, there will be more to come.

Do-It-yourself SaaS, a first step into the cloud?

Blogger: Richard Watson

This article on Bechtel’s strategy for reinventing its IT as an internal SaaS provider over at NetworkWorld is thought-provoking in many respects.  Leaving Bechtel’s infrastructure aside for a moment – I’ll leave that one for Drue Reeves in Data Centre Strategies to comment on - the exercise they went through in application portfolio management alone is astonishing, and surely some of their expected savings in IT budget is attributable to their leaner application portfolio.

I recently spoke to Annrai O’Toole, VP of Integration at the ERP SaaS vendor Workday.  We discussed walking his customers through a thought experiment like the process Bechtel went through: If you had to start again, would you start with your “development platform”: Java, Application servers, databases, etc.  He makes the case for an “application platform” based on ‘SWAG’ (Salesforce.com, Workday, Amazon and Google).

In this era of divestiture & enterprise reinvention – typified by the financial industry – that’s not too farfetched.   The landscape of investment banking is almost unrecognizable from the one I left 9 months ago.  The credit crunch has accelerated the process of disaggregating the banks into global holding companies (e.g. Citi), boutique hedge funds (e.g. funds have fallen by 20% on average) and specialized back-office service providers (e.g. Thomson/Reuters, ADP, etc.)  I’ve blogged previously on my skepticism for the success of migrating enterprise applications to a SaaS model. When an organization (or an industry) is reinvented, that issue becomes moot.

If enterprises feel they can fund such extensive portfolio management activities from OPEX, my punt is that we’ll see lots of it going on.  Over to Mike Rollings in Executive Advisory for his thoughts - Mike?

Does Adobe Have What It Takes To Win the RIA Race?

Blogger: JP Morgenthal

I’m attending Adobe MAX this week in San Francisco (Nov 17-19, 2008).  There’s been some very strong announcements by Adobe regarding the expansion of the Flash platform for enterprise and consumer markets.  Through it all one craw still stick in my hat and that is does Adobe have what it takes to win in the rich internet application race?

Take a quick glance at the RIA market and you will see that Adobe has a very strong presence in everything from media to enterprise applications.  With support from the likes of Salesforce.com and SAP, it would seem that they are a clear market leader.  That is if you discount Ajax as a platform unto itself and the fact that Microsoft has been a keen comeback competitor.  Moreover, Google is not likely to go linger about quietly in this race.

Additionally, up till now, Adobe’s success has been its ability to play nicely with other platforms.   PDF readers and Flash plug-ins are available for just about all critical platforms.  Will attempts by Adobe to take an ownership stake that steals thunder from these platforms affect their status?  To answer this we need to look at who would be affected by this.

The most significant victim is the desktop Java Runtime Environment.  The write-once, run-anywhere mantra is slowly being consumed by the Flash player and Adobe AIR.  Moreover, with Sun’s inability to gain support for Java FX, their current structural instability, Adobe’s growing presence on the desktop and in the browser, and the increase in the number of Flex programmers, the Java applet should be nothing more than a memory within a couple of years.

Next in line to be impacted is Google.  Google is a strong component of Ajax and invested heavily in tools and technologies that leverage Ajax for rich internet applications.  Unlike Sun, which has been unable to leverage their large installed base of server-side developers, Google has enabled Web developers to deliver very usable Web applications without requiring a significant learning curve.   Moreover, Google's main revenue stream is advertising and Flash-clients consuming Google services without also delivering the associated advertising has a limited life span.  This will require Google to act as a competitor to Adobe in the RIA race.

Finally, and never to be discounted, is Microsoft with Silverlight.  Currently a nascent player, Microsoft is bargaining for a position at the table and does not like to lose.  Microsoft’s .NET platform, which is the basis for Silverlight, has some powerful application features and offers more programming languages than just ActionScript, which could be an influential factor in attracting developers to the platform.  In addition, there are a number of .NET programmers now familiar with XAML and Windows Presentation Framework.

Adobe has always offered the market good adjunct capabilities, I hope with this recent attempt to gain adoption of a much larger platform, they haven’t bitten off more than they can chew.

Has the LAMP gone out?

Blogger: Anne Thomas Manes

I've been corresponding with Pam Derringer (TechTarget's SearchEnterpriseLinux.com's News Editor) during the past week. We started the conversation when she asked me to comment on the status of LAMP (Linux, Apache, MySQL, PHP/Perl/Python). My immediate reaction was, "I don't get very many questions about LAMP anymore." In fact, I rarely hear people mention LAMP anymore.

Does this mean the LAMP has gone out?

If you take the acronym literally, I'd say that LAMP has lost its luster. Not that there's anything wrong with Linux, Apache, MySQL, and PHP/Perl/Python, but I get the feeling that the last two letters in the acronym are getting supplanted by numerous alternatives. SQLite, which is lighter weight than MySQL, has become particularly popular in Ajax and mobile applications. And Ruby, Groovy, and JavaScript seem to have a lot more cache than PHP, Perl, or Python these days. Even Linux is subject to replacement. We went through a phase when folks were talking about WAMP -- replacing Linux with Windows. OpenSolaris and Mac OS X are other popular alternatives (SAMP and MAMP respectively). Of all the letters in the acronym, only Apache HTTP Server still reigns supreme.

If you use the acronym figuratively -- in which any letter in the acronym can be replaced with a suitable alternative, then I'd say that LAMP is alive and well. The figurative acronym refers to any lightweight, open source or low-cost platform. The "lightweight" aspect of the platform implies that you avoid "enterprisey" technologies, such as Java and .Net, and Oracle, DB2, and SQL Server. 

The fact that the term "LAMP" has faded from our vocabulary, I think, is an indication that the lighweight, open source platform alternative has gone mainstream. For info on one of the newer fads in this market, Burton Group subscribers can check out our document, Ruby on Rails Revisited.

Can you get by for a week with just an iPhone?

Blogger: Anne Thomas Manes

I conducted an interesting experiment last week. The Burton Group analyst and consulting teams convened in Salt Lake City (our headquarters) for our annual planning meeting. My laptop was sick, so I took the opportunity to hand it over to our IT team to rebuild it for me while I was in town. That left me with nothing more than my iPhone for four days.

We have a "no gizmos" rule at our planning meetings, so I had no compelling reason to have a full computer system with me -- I took notes on paper. My primary computer requirement for the week was to answer the occasional email -- but since the whole team was in town, my needs were fairly limited.

And I managed pretty well with just the iPhone. I did need to borrow a friend's laptop twice. The first time I needed to send an email containing a URL -- I really hate the fact that the iPhone doesn't have a copy/paste feature. The second time I needed to send a calendar invitation. Although I can create calendar events and accept/decline invitations, the iPhone doesn't allow me to send invitations. Other major limitations of the iPhone include lack of the VPN client I need to access our SharePoint site, and limitations associated with reading Word, Excel, and PowerPoint documents. But I anticipate that I will be able to leave my laptop home on a lot of my shorter business trips.

Software Process - Maturity, Formality, & Ceremony

Blogger: Kirk Knoernschild

The degree to which the software development process is defined, managed, measured, and controlled defines an organization’s process maturity.  Increased process maturity is a good thing because it’s an indication of an organization’s ability to develop and deliver software. Unfortunately, in focusing on process maturity, many teams fail to consider two other important software process classification schemes - formality and ceremony.

Process formality represents the discipline of the team in adhering to the practices defined by the software development process employed. Process ceremony represents the weight and rigidity of the software development process employed by the development team. Increased process ceremony corresponds to tighter controls placed on the development team. The difference between process formality and ceremony is subtle, but distinct.

For instance, a team may be very disciplined in capturing system requirements and documenting them by writing use cases. However, one team captures these requirements on hand-written notecards and reviews them with customers during weekly system demonstrations. Another team uses a standard use case template and requires customer sign-off on the requirements before development commences. Both teams are formal in that they capture and document requirements through use cases, but only the process used by the latter has a high degree of ceremony

Waterfall methods tend to be formal and ceremonial, whereas agile methods tend to favor formality with little ceremony. The Rational Unified Process (RUP) is a good example of an iterative method that wants to be formal, but often achieves that formality through ceremony. An unfortunate manifestation of RUP.

The unique challenges of individual software development projects vary widely. In general, process formality is a good thing while ceremony is wasteful and impedes progress. Only when teams lack the discipline to execute important lifecycle activities is ceremony necessary. Something to keep in mind as you look to increase software development process maturity.

When research worlds collide....

Blogger: Chris Haddad

Four years ago, the business case for SOA didn’t matter. Enterprise organizations pursued SOA initiatives based on desire to achieve ‘competitive advantage’ and ‘agility’ without specifying clear metrics and success criteria. Two years ago, I was asked by an IT professional to render a ‘SOA Sanity Check’ on a pending SOA project. The project scope was described as an exercise to implement a Business Process Management Suite (BPMS) in a test environment and “prove the suite would make the organization more agile.” My first question, “How do you measure agility?” was met with silence. The champion did not include clear success criteria or a well crafted business case as an integral part of the exercise.

Constantly refactoring the IT environment into more composable and dynamic building blocks is extremely important. The latest techniques, technologies, and tools more readily facilitate decomposing monolithic applications and systems into more re-usable and efficient assets. However, few IT professionals quantify and track the business benefit derived by their company’s application and service-oriented improvement initiatives (such as SOA, SDLC, and BPM). Missing the correlation between investment and benefit is hindering continued pursuit of transformational activities.

According to Gartner’s recently released “2008 SOA User Survey: Adoption Trends and Characteristics", “Overall, the two major reasons that organizations choose for not pursuing SOA are a lack of skills and expertise, and no viable business case.” Today’s budgetary environment of doing less with less makes it even more important for service oriented architecture (SOA) champions to make their business cases for SOA investment compelling and to create and maintain momentum. Gartner’s findings confirm the importance of Building the Business Case for Service Oriented Architecture Investment. In Burton Group’s recently published Methodologies and Best Practices document,Analyst Richard Watsonprovides timely, action-oriented recommendations. Richard updates our recommendations and insights for surviving the SOA business-case process. The guidance is based on our first-hand experience with organizations that have succeeded (and some that have failed) to make their case and obtain SOA initiatives funding.

Recent ‘news’is not surprising to Burton Group clients. Back on 29 June 2005 Burton Group’s Application Platform Strategies team publishedVantagePoint 2005-2006 SOA Reality Check, and the document concludes with the following statement “SOA adoption requires careful planning and a profound willingness to change…. It [SOA] requires developers to change the way they design systems, it requires extensive education and mentoring [emphasis added], and it requires different incentive systems.” We reiterate our position, and agree with our Gartner peers that “Organizations without a clear business case for SOA and without a plan to develop or acquire the necessary skills are justified in taking a cautious approach”

Chris Howard presents a way forward in an Executive Advisory Program Executive Summary  Addressing SOA Fatigue, "As a community of technology leaders, we need to change the conversation around SOA in order to counter SOA fatigue. We must reposition the discussion of SOA into a clear business context and remove the emphasis on SOA for SOA’s sake.” Burton Group team members look forward to collaborating with you to build a plan, develop your skills, and demonstrate business value.