A number of Forrester analysts from the Asia Pacific region attended the recent SAP analyst event in Singapore. Meetings with SAP global and regional executives and a large number of detailed breakout sessions over the 1½-day event all clearly indicate that SAP is continuing to try and reposition itself as a true generalized application platform player.
At the core of (almost all) initiatives is the HANA in-memory database technology. Whatever the problem, HANA will solve it (said with tongue planted very firmly in cheek). While the technology clearly has immediate performance benefits, particularly for existing SAP clients, net-new customers will likely need to compare the value of SAP’s offerings with others much more seriously.
HP seems to be on a tear, bouncing from litigation with one of its historically strongest partners to multiple CEOs in the last few years, continued layoffs, and a recent massive write-down of its EDS purchase. And, as we learned last week, the circus has not left town. The latest “oops” is an $8.8 billion write-down for its purchase of Autonomy, under the brief and ill-fated leadership of Léo Apotheker, combined with allegations of serious fraud on the part of Autonomy during the acquisition process.
The eventual outcome of this latest fiasco will be fun to watch, with many interesting sideshows along the way, including:
Whose fault is it? Can they blame it on Léo, or will it spill over onto Meg Whitman, who was on the board and approved it?
Was there really fraud involved?
If so, how did HP miss it? What about all the internal and external people involved in due diligence of this acquisition? I’ve been on the inside of attempted acquisitions at HP, and there were always many more people around with the power to say “no” than there were people who were trying to move the company forward with innovative acquisitions, and the most persistent and compulsive of the group were the various finance groups involved. It’s really hard to see how they could have missed a little $5 billion discrepancy in revenues, but that’s just my opinion — I was usually the one trying to get around the finance guys. :)
A recent RFP for consulting services regarding strategic platforms for SAP from a major European company which included, among other things, a request for historical and forecast data for all the relevant platforms broken down by region and a couple of other factors, got me thinking about the whole subject of the use and abuse of market share histories and forecasts.
The merry crew of I&O elves here at Forrester do a lot of consulting for companies all over the world on major strategic technology platform decisions – management software, DR and HA, server platforms for major applications, OS and data center migrations, etc. As you can imagine, these are serious decisions for the client companies, and we always approach these projects with an awareness of the fact that real people will make real decisions and spend real money based on our recommendations.
The client companies themselves usually approach these as serious diligences, and usually have very specific items they want us to consider, almost always very much centered on things that matter to them and are germane to their decision.
The one exception is market share history and forecasts for the relevant vendors under consideration. For some reason, some companies (my probably not statistically defensible impression is that it is primarily European and Japanese companies) think that there is some magic implied by these numbers. As you can probably guess from this elaborate lead-in, I have a very different take on their utility.
Last week IBM and ARM Holdings Plc quietly announced a continuation of their collaboration on advanced process technology, this time with a stated goal of developing ARM IP optimized for IBM physical processes down to a future 14 nm size. The two companies have been collaborating on semiconductors and SOC design since 2007, and this extension has several important ramifications for both companies and their competitors.
It is a clear indication that IBM retains a major interest in low-power and mobile computing, despite its previous divestment of its desktop and laptop computers to Lenovo, and that it will be in a position to harvest this technology, particularly ARM's modular approach to composing SOC systems, for future productization.
For ARM, the implications are clear. Its latest announced product, the Cortex A15, which will probably appear in system-level products in approximately 2013, will be initially produced in 32 nm with a roadmap to 20nm. The existence of a roadmap to a potential 14 nm product serves notice that the new ARM architecture will have a process roadmap that will keep it on Intel’s heels for another decade. ARM has parallel alliances with TSMC and Samsung as well, and there is no reason to think that these will not be extended, but the IBM alliance is an additional insurance policy. As well as a source of semiconductor technology, IBM has a deep well of systems and CPU IP that certainly cannot hurt ARM.
When I started as an architect, I was part of the team called “IT Architecture.” It was clear what we did and who we did it for – we standardized technology and designs so that IT would be more reliable, deliver business solutions more quickly, and cost less. We were an IT-centric function. Then the term “Enterprise Architecture” came in – and spurred debates as to “isn’t EA about the business?,” “what’s the right scope for EA?,” and “should EA report to the CEO?” We debated it, published books and blogs about it – but it didn’t change what most architects did; they did some flavor of IT Architecture.
Meanwhile, the interplay of business and technology changed . . . Technology became embedded and central to business results, and business leaders became technology advocates. The locus of technology innovation moved from the “heavy lifting” of core system implementations to the edges of the business, where business staff see opportunities and demand more autonomy to seize them. For enterprise architects, this means that regardless of what EA has been, in the future it must become a business-focused and embedded discipline. Mapping this shift is a key theme of Forrester’s Enterprise Architecture Forum 2011.
Gene Leganza, who will be presenting the opening keynote “EA In The Year 2020: Strategic Nexus Or Oblivion?,” states it this way:
Step back and think: How would you answer the question, “What does your IT group deliver to your business?” Your answer will indicate how you think about the relationship between business and technology, and, in turn, it will affect your business agility and your business-IT alignment.
If you answer anything close to “IT delivers and integrates solutions to meet business requirements,” your mental model boils down to thinking that your solutions support the business: Business is one thing; solutions are a separate thing. If the business has a problem, let it come ask IT for some application to address the problem — maybe IT will even help the business figure out what it needs. Each application supports (typically overlapping) parts of the business, and IT performs whatever behind-the-scenes integration is necessary to gain some degree of coherency across the whole. The result is the sort of siloed spaghetti application mess that most organizations are dealing with — even if SOA and BPM and the rest make it easier to deal with.
Can you remember a year when your business both (1) grew in a healthy way and (2) changed more slowly than the year before? Besides a company’s early startup years, such would be the exception, not the rule. So, in 2011, your business is likely to continue accelerating its pace of change. A recent Forrester report, The Top 15 Technology Trends EA Should Watch: 2011 To 2013, named both business rules and SOA policy as items for your watch list — because both of them help accelerate business change.
Back in the mainframe days — and even into minicomputer, client/server, and Web applications — nearly all of the business logic for every application was tightly wrapped up in the application code. A few forward-thinking programmers might have built separate parameter files with a small bit of business-oriented application configuration, but that was about it. But, business changes too quickly to have all of the rules locked up in the code.
Some have tried the route that businesspeople ought to do their own programming — and many vendor tools through the years have tried creatively (though unsuccessfully) to make development simple enough for that. But, business is too complex for businesspeople to do all of their own programming.
Enter business rules, SOA policy, and other ways to pull certain bits of business logic out of being buried in the code. What makes these types of approaches valuable is that they are targeted, contained, and can have appropriate life cycles built around them to allow businesspeople to change what they are qualified to change, authorized to change, and have been approved to change.
Forrester’s recent book, Empowered, describes the type of technology-based innovation by frontline employees that can cause nightmares for enterprise architects. New tools for business innovation are readily available to anyone, ranging from cloud computing and mobile apps to social networks, scripting languages, and mashups. Faced with long IT backlogs and high IT costs, frontline employees are building their own solutions to push business forward.
What worries architects is that (1) solutions built with these new tools — with little or no vetting — are being hooked to enterprise systems and data, opening potentially big risks to reliability and security, and (2) the siloed, quick-hit nature of these solutions will drive up ongoing costs of maintenance and support. Traditionally, architects use enterprise standards as their primary tool to ensure the quality, efficiency, and security of their organization’s technology base. However, when applied in the typical “lockdown” fashion, standards can stifle innovation — often because vetting a new technology takes longer than the perceived window of business opportunity.
To deal with these conflicting pressures, architects must forge a new equation between responsiveness and technology control. The business value of responsiveness, combined with the typically limited size of enterprise architecture teams, means that most organizations cannot wait for architects to vet every possible new technology. Thus, you must find ways to use architecture to navigate the tension between the business value of responsiveness and the business value of a high-quality technology base. The key is to build innovation zones into your architecture; Forrester defines these as:
As I discuss with clients the developing notions of Forrester's Business Capability Architecture (see blog post #1 and blog post #2), I have found it important to distinguish between different levels of scope for technology strategy. The primary distinctions have to do with (a) the degree to which a strategy (and the architecture it promulgates) aims to account for future change and (b) the breadth of business and technology scenarios addressed by the strategy.
Thus, I define a four-part technology strategy taxonomy along a two-dimensional continuum with (a) and (b) as axes (IOW, the four parts are archetypes that will occur in varying degrees of purity), to wit:
Type 1: project strategy for successful solution delivery. With Type 1 strategy, the goal is simply to achieve successful project delivery. It is beyond the strategy’s scope to consider anything not necessary to deliver a solution that operates according to immediate business requirements. Future changes to the business and future changes in technology are not considered by the strategy (unless explicitly documented in the requirements). The classic case for a Type 1 strategy is when an organization definitively knows that the business scenario addressed by the solution is short-lived and will not encounter significant business or technology change during the solution’s lifetime (history argues that this is a risky assumption, yet sometimes it is valid).
In discussions on cloud computing, I often talk to architects who have been told to create a "cloud strategy." This sounds appropriate enough, but there’s a devil in the details: When the task is "create a Technology X strategy," people often center strategy on the technology. With cloud, they aim to get a good definition of pure cloud and then find places where it makes sense to use it. The result is a technology strategy silo where cloud is placed at the center and usage scenarios are arranged around it. The problem with this is three-fold:
Considering the full business dynamics of any given usage scenario, there is a wide continuum of often strongly competing alternatives to pure cloud (including cloud-like and traditional options).
The rapid pace of market development means that business value equations along this continuum of options will keep changing.
Your business needs integrated strategy for many technologies, not simply a siloed cloud strategy.