IBM's zEnterprise Is A Game Changer For Application-Platform Choice

Phil Murphy

A quick note on a big announcement today by IBM that is being rolled out as I write this. No, I don't have a crystal ball - my colleague Brad Day and I spent a day in Poughkeepsie in late June for the full scoop - provided under NDA. The announcement is massive, so I'll just lay out the high points and a few of my thoughts on what it means to apps folks. I'll leave the deeper I&O/technical details to Brad and others in subsequent posts and research. My goal here is to get a conversation going here on what it may mean to apps people in your IT shops.

What's in the zEnterprise announcement?

  • It's a new computing environment that unifies Linux, AIX, and z/OS on a new server complex that includes mainframe servers, x86, and Power7 blades under a single set of management software: the zEnterprise Unified Resource Manager (URM).
  • A 10 Gb private data network joins the new z server (z196) and zBX - an ensemble that houses racks of x86 and Power7 blades. It also includes an intra-ensemble network that is physically isolated from all networks, switches, and routers - permitting removal of blade firewalls.
    • One client claims a 12-to-1 reduction in network hops by eliminating blade firewalls.
  • The z196 permits up to 96 Quad-core 5.02 ghz processors, 80 available for customer use, and 112 blades.

What is the impact on applications people and application-platform choice?

zEnterprise is a monster announcement that heralds a long laundry list of improvements - it would be impossible to cover all of the ramifications in a single blog post; however, a brief glimpse of some of the most notable improvements that affect applications folks include (zEnterprise as compared to z10):

Read more

Use A Four-Step Approach To Select The Right BI Services Provider

Boris Evelson

BI projects are never short, and, alas, many of them don't end since a fast-paced business environment often introduces new requirements, enhancements, and updates before you're even done with your first implementation. Therefore, we typically recommend doing sufficient due diligence upfront when selecting a BI services provider — as you may be stuck with them for a long time. We recommend the following key steps in your selection process:

  1. Map BI project requirements to potential providers. Firms should use Forrester's "BI Services Provider Short-Listing Tool" to create a shortlist of potential providers. With the tool you can input details about your geographic scope, technology needs, and the type of third-party support you need (i.e., consulting versus implementation versus hosting/outsourcing).  The tool then outputs a list of potential providers that meet the criteria. For each potential fit, the tool also generates a provider profile summary that offers key details around practice size, characteristics, and areas of expertise.
Read more

Join Me For A BI Strategy Workshop In Cambridge, Mass., On October 19, 2010

Boris Evelson

Business intelligence (BI) continues to be front and center on the agendas of businesses of all sizes and in all industries and geographies. Ever-increasing data volumes, complexity of global operations, and demanding regulatory reporting requirements are just some of the reasons. But also, more and more businesses realize that BI is not just a tool but rather a key corporate asset that they can use to survive, compete, and succeed in an otherwise increasingly commoditized global economy.

However, we consistently find that many BI initiatives fail and even more are less than successful. Well, maybe we can help. Even if just a little bit. Come to our interactive one-day BI Strategy Workshop to learn the fundamentals and best practices for building effective and efficient BI platforms and applications. The Workshop will also include hands-on exercises with tangible deliverables that you can take back to your teams to help you jump-start or adjust the course of your BI initiatives.

Why attend? Because hundreds of organizations have already benefited from reading Forrester research and working with Forrester analysts on the topics covered in this Workshop. I plan to present Forrester’s most recent research on:

  • Why are BI initiatives at the top of everyone's agenda, while many of them still fail?
  • What are some of the best practices necessary to achieve successful BI implementations?
  • What are some of the next-generation BI technologies and trends that you can't overlook, such as Agile BI and self-service BI?
  • How do you assess your BI maturity so that you can get a solid starting point on the way to your BI vision and target BI state?
  • How do you assess whether your organization has a solid BI strategy?
Read more

Join Our Data Management Tweet Jam On MDM’s Next Evolution: Tuesday, July 20, 3-4 PM ET

Noel Yuhanna

Many large organizations have finally “seen the light” and are trying to figure out the best way to treat their critical data as the trusted asset it should be. As a result, master data management (MDM) strategies and the enabling architectures, organizational and governance models, methodologies, and technologies that support the delivery of MDM capabilities are…in a word…HOT! But the concept of MDM -- and the homegrown or vendor-enabled technologies that attempt to deliver that elusive “single version of truth,” “golden record,” or “360-degree view” -- has been around for decades in one form or another (e.g., data warehousing, BI, data quality, EII, CRM, ERP, etc. have all at one time or another promised to deliver that single version of truth in one form or another).

The current market view of MDM has matured significantly over the past 5 years, and today many organizations are on their way to successfully delivering multi-domain/multi-form master data solutions across various physical and federated architectural approaches. But the long-term evolution of the MDM concept is far from over. There remains a tremendous gap in what limited business value most MDM efforts deliver today compared to what all MDM and data management evangelists feel MDM is capable of delivering in terms of business optimization, risk mitigation, and competitive differentiation.

What will the next evolution of the MDM concept look like in the next 3, 5, and 10 years? Will the next breakthrough be one that’s focused on technology enablement? How about information architecture? Data governance and stewardship? Alignment with other enterprise IT and business strategies?  

Read more

Software Quality Is More Than Just Lack Of Defects

Mike Gualtieri

My colleague Margo Visitacion and I are finishing up a new report, Seven Pragmatic Practices To Improve Software Quality, that will publish in a few weeks. We realized that not everyone has the same definition of quality. More often than not application development professionals define software quality as just meaning fewer bugs. But software quality means a whole lot more than just fewer bugs.

Forrester defines software quality as:

Software that meets business requirements, provides a satisfying user experience, and has fewer defects.

 

What It Means: Quality Is A Team Sport

Quality must move beyond the purview of just QA professionals and must become an integrated part of the entire software development life cycle (SDLC) to reduce schedule-killing rework when business requirements are misunderstood, improve user satisfaction, and reduce the risks of untested nonfunctional requirements such as security and performance.

Where Do You Draw The Lines Between Business And IT Ownership Of Data And Information?

Boris Evelson

I get many questions on this subject and it often turns into almost a religious debate. Let's throw some structure into it. Here's a decision-to-raw-data stack.

  1. Decisions
  2. Strategy
  3. Policies
  4. Objectives (e.g., clear understanding of what is driving revenue performance)
  5. Goals (e.g., achieve x% income growth)
  6. Calculated metrics (any combination, variation of the standard metrics or KPIs)
  7. KPIs (e.g., profitability, liquidity, shareholders value)
  8. KPMs (e.g., enterprise value, trailing/forward price/earnings)
  9. Metrics (e.g., fee income growth %, non-fee income growth %)
  10. Dimensions (part of MDM, e.g., customers, customer segments, products, time, region)
  11. Pre-calculated attributes (standard, cross-enterprise metrics, KPIs, and KPMs)
  12. Pre-built aggregates (used to speed up reports and queries)
  13. Analytical data (DW, DM)
  14. Operational data (ERP, CRM, financials, HR)

Obviously, it's never a clear-cut, binary decision, but in my humble opinion:

  • 1-6 should emphasize business ownership
  • 10-14 should emphasize IT ownership
  • 7-9 is where it gets murky, and ownership depends on whether metric/KPI/KPM is: 1) standard and fixed, 2) fluid and changes frequently, 3) different by product, line of business, or region.

What did I miss? Thoughts?

Lest We Forget SAP

John R. Rymer

The "smart money" seems to be betting against SAP. I hear all the time about the company's bleak prospects for the future. A client conversation last week reminded me of how strong SAP’s position is, despite its many issues.

This client, a worldwide manufacturer, is investing hundreds of millions of dollars in SAP software for its worldwide supply chain, financial management and reporting, inventory and order management, etc. The new SAP environment will replace hundreds of disparate applications and, ideally, result in far more efficient operations, far better visibility into operations, and far more uniform products around the world. The members of this client’s SAP implementation team have finished SAP implementation marathons before (at other employers). They know the good, the bad, the ugly.

In this manufacturer, SAP is sticky for four reasons.

Read more

Best practices for using spreadsheets as BI tools

Boris Evelson

By Boris Evelson

We all know that the war of fighting the proliferation of spreadsheets (as BI or as any other applications) in enterprises has been fought and lost. Gone are the days when BI and performance management vendors web sites had “let us come in and help you get rid of your spreadsheets” message in big bold letters on front pages. In my personal experience – implementing hundreds of BI platforms and solutions – the more BI apps you deliver, the more spreadsheets you end up with. Rolling out a BI application often just means an easier way for someone to access and export data to a spreadsheet. Even though some of the in memory analytics tools are beginning to chip away at the main reasons why spreadsheets in BI are so ubiquitous  (self service BI with no modeling or analysis constraints, and little to no reliance on IT), the spreadsheets for BI are here to stay for a long, long, long time.

With that in mind, let me offer a few best practices for controlling and managing (not getting rid of !) spreadsheets as a BI tool:

  1. Create a spreadsheet governance policy. Make it flexible – if it’s not, people will fight it. Here are a few examples of such policies:
    • - Spreadsheets can be used for reporting and analysis that support processes that do not go beyond individuals or small work groups vs. cross functional, cross enterprise processes  
    • - Spreadsheets can be used for reporting and analysis that are not part of mission critical processes
Read more

Oracle OBIEE 11g Launch: "We are back!"

Boris Evelson

Whoever said BI market is commoditizing, consolidating and getting very mature? Nothing can be farther from the truth. On the buy side, Forrester still sees tons of less-than-successful BI environments, applications and implementations as demonstrated by Forrester's recent BI Maturity survey. On the vendor/sell side, Forrester also sees a flurry of activity from the startups, small vendors and large, leading BI vendors constantly leapfrogging each other with every major and minor release.

In terms of the amount of BI activity that Forrester sees from our clients (from inquiries, advisories and consulting) there’s no question that SAP BusinessObjects and IBM Cognos continue to dominate client interest. Over the past couple of years Microsoft has typically taken the third place, SAS  fourth place and Oracle the distant fifth. But ever since Siebel and Hyperion acquisitions, the landscape has been changing, and we now often see Oracle jumping into third place, sometimes leapfrogging even Microsoft in the levels of monthly interest from Forrester clients.

Read more

Your Future Needs A Type 4 Technology Strategy

Randy Heffner

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).
Read more