There is growing evidence of a harmonic convergence of Infrastructure and Operations (I&O) with Security and it is hardly an accident. We often view them as separate worlds, but it’s obvious that they have more in common than they have differences. I live in the I&O team here at Forrester, but I get pulled into many discussions that would be classified as “security” topics. Examples include compliance analysis of configuration data and process discipline to prevent mistakes. Similarly, our Security analysts get pulled into process discussions and other topics that encroach into Operations territory. This is as it should be.
Some examples of where common DNA between I&O and Security can benefit you and your organization are:
Gain economic benefit by cross-pollinating skills, tools, and organizational entities
Improve service quality AND security with the same actions and strategies
Learn where the two SHOULD remain separate
Combine operational NOC and security SOC monitoring into a unified command center
Develop a plan and the economic and political justifications for intelligent combinations
IT has too many separate portfolios to manage, and that hinders its ability to help business change. We have project portfolios, application portfolios, technology portfolios, and IT service portfolios – each managed in silos. These portfolios are all IT-centric – they generally mean nothing to business leaders. The business has products, customers, partners, and processes – and the connection between these business portfolios and the IT portfolios isn't readily apparent and usually not even documented. Change in the business – in any of these areas – is connected to IT only in the requirements document of a siloed project. Lots of requirement documents for lots of siloed projects leads to more complexity and less ability to support business change.
How do we connect these business concepts to IT? What's the "unit" that connects IT projects, apps, and technology with business processes and products?
It's not "business capabilities" – they are an abstraction most useful for prioritizing, analysis, and planning. We need a term to manage the day-to-day adaptation and implementation of these capabilities – the implementation with all its messiness such as fragmented processes and redundant apps – that we can use to manage any type of change.
We believe the best term for this unit is "business services," with this definition:
The output of a business capability with links to the implementation of people, processes, information, and technology necessary to provide that output.
If anything exemplifies the extended enterprise, it's the notion of the "API economy": Unlocking value in your organization's unique data and services by publishing open APIs (application programming interfaces) for access by third parties. As Laura Koetzle notes, business leaders today are prioritizing growth above all -- and fostering a third-party developer ecosystem is becoming a great way to boost revenue. Best Buy, eBay, and USA Today are examples of companies with APIs and external developer communities.
But, but, but...just how secure is an open API? Especially if you, the security professional, can't fully control these external developers' actions? This is where it gets exciting, because security and identity-based access control are enablers of these new business opportunities. After all, an API of this sort is essentially a digital product whose use must be metered.
Many organizations in this position are turning to the OAuth technology to solve a host of security challenges that arise from opening up APIs. I'm excited to be bringing the latest in OAuth business cases, adoption news, and recommendations to my Forrester Security Forum track session on "Securing And Identity-Enabling Monster Mashups." Hope to see you at the Forum November 9-10 in Miami!
(Got a great API security story, or maybe some questions? Don't wait till November; feel free to share in a comment here, or ping me on Twitter using the #FSF11 hashtag.)
As promised in my blog last week, here is part 2. In part 1, I introduced the two trends reports we did this year and showed the list of trends for business technology. These are trends and technologies to consider first with your "business hat" on. This blog post lists the other 10 trends to view first from a technology lens because they are of lower interest or impact to the business.
We have created four new categories to make IT stakeholder identification easier: 1) application platforms will be of high interest to your app dev and management teams; 2) integration will be of interest to app dev, data integration specialists, and even process folks (considering that processes can and should be integrated with apps and data); 3) infrastructure and operations; and 4) mobile computing, which spans infrastructure, app dev, and possibly line-of-business relationship managers who are very keen on mobility. And don't forget your security and compliance stakeholders, who will generally care about all of these!
Before listing the trends and technologies, I also want to introduce a new twist to our research this year - we have identified four major themes that run through many of our business technology and technology trends. These themes are so broad and far reaching that we thought it worth calling them out separately; we are advising our clients to understand these themes as the context for responding to individual trends:
I handle many inquiry calls from clients asking for help negotiating with large suppliers, and often they claim the supplier is a strategic partner. I’ve noticed that many clients use that term, but when I ask them what it actually means in practice, I get varying responses. So Forrester recently surveyed over 150 sourcing and vendor management (SVM) professionals to ask them what they expect to get from strategic partners, and what they offer in return. I was bit disappointed with the results. For instance, while 68% said they would always expect partners to give them the best possible discount, only 6% said they would always make the partner their sole source for specific technology categories.
What’s wrong with this picture? Well, to quote Godfather 2, when explaining Hyman Roth’s longevity, Johnnie Ola says, “He always made money for his partners.” That concept doesn’t seem to apply in the technology world. On the one hand, buyers complain about vendors’ unfair policies (see my recent report Buyers Should Reject Unfair Licensing Rules) and transactional sales approach. Yet OTOH they want to squeeze their partners’ margins while still expecting them to sell their wares site-by-site and product-by-product around their enterprise. As one senior software executive told me the other day, “Sure, I’ll waive my usual policies for partners, but only if they let me off the huge cost of supporting individual, small product buying decisions.”
Lexmark International acquired Netherlands-based Pallas Athena and will combine the company with its recent acquisition of Perceptive Software, a fast-growing ECM provider. Together this is a very complete software unit for the ECM, BPM, and dynamic case management market. Pallas received good reviews well in the recent Forrester Wave™ for dynamic case management solutions and has a strong overall BPM technology. North American exposure, and distribution in general, was the big issue. Perceptive had an easy-to-deploy workflow management solution but lacked case managenent or extension beyond departmental applications. Combining Perceptive and Pallas Athena should should work well. The challenge and potential is to create synergy and focus with Lexmark’s growing managed print services business — which means focusing on office document automation that supports the knowledge worker.
In 2007 Larry Elison said: "We think the paradigm for doing business, how people do their daily jobs is changing and is moving to a search paradigm.” For years Oracle has worked on weaving its search functionality into and across Oracle applications. It's called Secure Enterprise Search (SES) and it's invisible to Content & Collaboration (C&C) professionals because it's inside the Fusion platform, rarely sold as a standalone solution. With SES integrated in Oracle products, Oracle envisions "action-oriented" enterprise search. What does that look like? When workers don't just search for pending expense reports, they also can pay them from the search UI.
When search is an embeddable service, it makes it easier to use search to get tasks done. This is why I think infrastructure vendors (HP, Oracle, Microsoft, Dassault) acquiring specialized vendors (Autonomy, Endeca, Fast, and Exalead, respectively) is a good thing for C&C professionals. What's missing from these marriages? Semantic search capabilities -- where search surfaces unstated concepts and allows users to visualize the patterns and trends locked inside volumes of text. (IBM is one to watch for this vision -- a leader in BI, they have recently commingled their search and content analytics technology to create a new product.)
This is a very smart move by Oracle. Until the Siebel and Hyperion acquisitions, Oracle was not a leader in the BI and analytics space. Those acquisitions put them squarely in the top three together with IBM and SAP. However, until this morning, Oracle played mostly in the traditional BI space: reporting, querying, and analytics based on relational databases. But these mainstream relational databases are an awkward fit for BI. You can use them, but it requires lots of tuning and customization and constant optimization — which is difficult, time-consuming, and costly. Unfortunately, row-based RDBMSes like IBM DB2, Microsoft SQL Server, Oracle, and Sybase ASE were originally designed and architected for transaction processing, not reporting and analysis. In order to tune such a RDBMS for BI usage, specifically data warehousing, architects usually:
Denormalize data models to optimize reporting and analysis.
Build indexes to optimize queries.
Build aggregate tables to optimize summary queries.
Build OLAP cubes to further optimize analytic queries.
My colleague and friend Mike Gualtieri wrote a really interesting blog the other day titled "Agile Software Is A Cop-Out; Here's What's Next." While I am not going to discuss the great conclusions and "next practices" of software (SW) development Mike suggests in that blog, I do want to focus on the assumption he makes about using working SW as a measurement of Agile.
I am currently researching that area and investigating how organizations actually measure the value of Agile SW development (business and IT value). And I am finding that, while organizations aim to deliver working SW, they also define value metrics to measure progress and much more:
Cycle time (e.g., from concept to production);
Business value (from number of times a feature is used by clients to impact on sales revenue, etc.);
Productivity metrics (such as burndown velocity, number of features deployed versus estimated); and last but not least
Quality metrics (such as defects per sprint/release, etc.).
Is it a blog? Is it a musing (that’s not “amusing”)? Or is it just a cheap attempt to pick the brains of others smarter than myself? Does it matter? Can I do anything other than ask questions?
My point (or at least my line of thinking while I plan a couple of ITIL-related Forrester reports) is that we spend a lot of time talking about what to do (or more likely what not to do) when "adopting ITIL," but how often do we talk about whether we have been successful in applying the concepts of ITIL, the processes, and the enabling technology for business benefit?
Maybe it is because we quote the mantra that “ITIL is a journey” and we can’t see a point in time where we can stop and reflect on our achievements (or lack of)? Maybe we segue too quickly from the ITIL-technology adoption project into the firefighting realities of real-world IT service management? Whatever the potential barriers to taking stock, where is that statement that describes what we have achieved and our relative level of success?
Looking at this logically (fatal mistake, I know), assuming (potentially a big assumption) that there was a business case for the “ITIL adoption project” where is the post implementation review (PIR)? Where can we look to see the realization of business benefits (I deliberately didn’t say “IT benefits” BTW)? I’m trying not to be cynical but, even if we forget the formalities of a PIR, how many I&O organizations can quantify the benefits achieved through ITIL adoption? More importantly what has been achieved relative to the potential for achievement? Where did we get to in our desired-future-state?