Some big names in the IT industry – Microsoft’s CEO Steve Ballmer, for example, and Adobe’s CEO Shantanu Narayen – have publicly said they think that the growth of the cloud for hosting software will lead to a decrease in software piracy. Software piracy costs an estimated $51 billion globally every year, according to IDC in its 2010 report, The Economic Benefits of Reducing Software Piracy. While these executives may be right about a decline in the problem of rampant use of unlicensed software that has long troubled tech vendors, the cloud actually may create piracy problems of another sort: The theft of data and services that relate to applications running in the cloud.

Sure, data theft always has been an issue for companies. But with data increasingly found on the cloud’s “open seas” – make that “open skies” – it’s so much more easily boarded and taken for ransom by modern-day Blackbeards. When that data is intellectual property associated with your services, imagine the potential for revenue hijacks. As an example of an incident foreshadowing these concerns, look no further than the case where SAP’s TomorrowNow division illegally downloaded Oracle’s online support material to provide Oracle’s own customers with an alternate means of software services. The suit that began in 2007 finally ended late last year when SAP was ordered to pay Oracle $1.3 billion in damages.

It’s time to start architecting a global defense against such forms of piracy. Your work starts with thinking about what defenses need to be shored up – whether, for example, security holes exist that will allow your data in the cloud to be stolen. Pirates might want to realize many ends from looting IP data, including digital terrorism where such data is held for ransom, or even to manipulate the stock market by creating a negative perception of a company's reputation.

Enterprise Architecture to the Rescue

The enterprise architect has perhaps the most critical role to ensure the right technology is used to fight this battle against pirates in the sky. My strategy for success is comprised of a multi-pronged attack:

• Network architecture: Diversity matters in your stock portfolio and it matters for architecting networks that extend into the cloud, too. The cloud, platform choices, global distribution of services, and layers of abstraction offer enough obfuscation to thwart intrusion. Oh, and it leads to a more scalable deployment as well; win-win!
• Data architecture: Design for encryption, keep (where appropriate)data within your private cloud , and watch out for enterprise mash-ups. For one thing, control access to your critical data where it’s required (i.e. financial data that require audited, metered, access). Beyond protecting the obviously critical databases, don’t overlook apps’ administrative and support systems whose data lives in the cloud.
• Directional Authentication: Have your users come from a single, known source of authentication or clearing house to reduce the chances of intrusion. Alternatively, you can use two-factor authentication, which requires two forms of proof that your users are who they say they are.
• Intrusion and Theft Detection: In some ways, it’s a losing battle to fight the bad guys. Just make sure you know the instant they’re at your front door. That effort requires coordination with CSOs.

Let me expand on those thoughts a bit, starting with network architecture. With the cloud, network architecture goes beyond adding firewalls and routers in all the right places. It means choosing a cloud vendor with security guarantees; distributing your services beyond a single hosting provider; and building a private in-house cloud to house your most critical business components—that is, black box algorithms, customer data, and other valuable IP.

In terms of your data architecture, don’t assume all threats are external; often the biggest danger comes from within. Both accidental data exposure, and ill-intent can put you and your data at risk. Ensuring that your data is encrypted within the confines of your own firewalls, and not allowing applications to use internal data without going through proper gateways, will help thwart internal attacks and risks (accidental or not).

All that said, it’s my opinion that intrusion detection is where you should put most of your time, energy, and money. Many companies offer products and services to help protect your software assets, as well as your customer data, from theft and piracy. For starters, authentication, authorization and auditing software such as CA SiteMinder offers you peace of mind that access to your cloud or web-based services is secure, while providing your customers with the convenience of single sign-on across your products and services. Other products offer security at other stages of online software usage, such as when users initially sign up for access to your software, or make self-service support requests. These areas often are overlooked in terms of their security needs, and strong identity management software is a must here.

You should consider user activity reporting software, such as CA's User Activity Reporting Module, which securely tracks your users' activity across your online software and services to identify potential security breaches. This type of activity logging is sometimes mandated, such as with SOX compliance, and HIPAA privacy laws.

Of course, your company’s CSO is responsible for a corporate-wide vision of security in every facet of the business. This goes beyond architecting security into an application or suite. So, while it’s your job to ensure the systems your company deploys are secure, it’s the CSO’s job to align this across all software produced, bought, sold, and acquired, as well as respond to security incidents, and deal with the exposure and liabilities associated. Therefore, when architecting a software product’s security detection and response systems, be sure to align with your CSO and her company-wide strategy for dealing with risk in this area. (This slidecast provides a lot of advice about working with your IT security team to help ensure that application security is built in, not bolted on.)

I’ll reiterate: While it may be impossible to prevent data piracy, the best defense may be early detection when it does happen.

Breaking the Pirate Code

To summarize, your architecture to thwart modern software piracy should include a combination of the following:

• Obfuscation through a scaled-out PaaS/Cloud strategy (no single source);
• Private cloud, where appropriate, for critical IP, and customer data, too;
• Data encryption at the source, inside an internal walled garden (trust no one);
• Directional authentication: single sign-on from a known secure source (i.e. CA SiteMinder), and/or two-factor authentication (such as CA’s Arcot set of solutions);
• Detection, detection, detection.

You also might find it helpful to review some other articles Smart Enterprise Exchange has authored on cloud security, including Security and the Cloud Must Co-exist; Unlocking Cloud Security; and Cloud Security: From Barrier to Enabler. Also check out videos like this one Cloud Computing: The Enterprise Advantage Video Series.

There’s always a lot of discussion in social forums from enterprise architects about which tools they should be investigating. Which one will best assist in their modeling efforts? What’s the cost? What products can help them get up to speed quickly, perhaps with the help of templates and preconfigured repositories? So it’s not surprising that the recent update of the Netherlands-based Institute for Enterprise Architecture Developments’ (IFEAD) Tool Selection Guide got its fair share of play in the Twittersphere. Version 6.2 promised to deliver a renewed overview of what matters most in the current Enterprise Architecture tool market, as well as assessments of vendors and their offerings, along with fundamental requirements for smart EA tool selections.

We at Smart Architect agree with the insights of the guide’s editorial writer and IFEAD’s founder and Chairman of the Board, Jaap Schekkerman, that: “important to adoption of an enterprise architectural approach is the availability of tools to support the development, storage, presentation and enhancement of Enterprise Architecture representations.” Without some tool to support and manage the development, maintenance and implementation of Enterprise Architectures, the guide notes, the ability for them to be useful and provide business value is in question. Toward that end, Version 6.2 considers as part of the review framework both tools’ basic functionality (methodologies and models, automation, customization, repository and so forth), and their utility to the requirements of different architects (enterprise and solution architects, as well as strategic planners and others in the enterprise program management chain).

You’ll of course want to peruse the guide at greater length yourself. But we’d like to highlight a few issues to keep front-and-center as you think about what tools to bring into your Enterprise Architecture mix:

• A tool may support multiple complementary methodologies and modeling approaches, such as process modeling and data modeling, and that also goes for offering competing approaches. The guide reminds readers that, in the first case, it’s important to understand how well the different approaches can be used together in an overall enterprise architectural approach. And in the second — such as two approaches to data modeling — to ascertain how well the data being modeled can be moved between these different perspectives.
• When it comes to analyzing or manipulating developed Enterprise Architecture models, does the tool go beyond examining how correct or complete the model is relative to the particular modeling approach used, to more sophisticated support? For instance, can the model be interrogated in some way? Can different versions of models be compared so that current and planned enterprise architectures can be measured against one another? Can you choose to represent or view models from varying perspectives, such as particular classes of entities?

   

• Keep a heads-up on the costs front. That includes not only the tool license, but ask whether those licenses can be shared among a large group of users, whether there are discounts for site-license purchases or for government or nonprofit groups. And don’t forget about the after-sales costs, including yearly maintenance.
• The preface to the guide’s extensive tool candidate requirements checklist shouldn’t be passed over lightly. Mark it up with a big exclamation point to ground the process in the real world, as it advises the involvement of all stakeholders in agreeing on objectives for acquiring and using a comprehensive modeling tool, as well as the translation of enterprise-level objectives into actual requirements for both vendor presence and performance.

And to this valuable resource we’d like to add a few more considerations:

• The guide obviously would be remiss if it didn’t mention things such as training, help and user interface goodies, which it does. But it’s worthwhile to think of these all more holistically, in terms of how they come together to deliver an ease-of-use experience that will get the entire team to embrace the tool rather than resist it. Consider, after all, that products such as Visio and Visual Studio still hold sway with many in the community.
• To take the point about stakeholder involvement a step further, it’s prudent to consider the stakeholder with the purse strings. In many organizations, that will be the CIO. Experts in the Enterprise Architecture arena have recommended that an EA tool must take into account the context of business processes and productivity, and to help create an architecture that makes information an asset in terms of how it can be repurposed and optimized, and its quality improved. That hits home for the CIO.
• Finally, as important as are the tools used to visualize and document the Enterprise Architecture — and they are very important — remember that ultimately it is the Enterprise Architecture itself that is THE vital tool for the organization. So, there’s more to the enterprise architect’s role than helping select the right product to build an enterprise where change and complexity can be managed in an agile manner, or being fluent in its use (indeed, that’s a recurring theme throughout the Smart Architect group, including our slidecast “7 Steps to Transform Your Enterprise Architecture Practice” . The enterprise architect must continually communicate the value of the work to the rest of the enterprise community — alas, there’s no tool to help on that front. That’s all in your own hands, my friends.

That all said, we’d love to hear your thoughts on what in The Tool Guide stands out in your mind. Please feel free to post your comments here.

Let’s face it: The IT Infrastructure Library (ITIL) is the 800-pound gorilla in the world of frameworks. In so many respects, ITIL has had a tremendously positive impact on the ability of companies to deliver IT service support capabilities. Yet, over the course of its 20-year history — particularly with version 3 — the ITIL framework has had applied to it some extended interpretations of just what it is and does. Some have concluded, for example, that it offers best practices for portfolio or service management, when in fact ITIL doesn’t even specifically define good processes for IT infrastructure and operations disciplines such as change management. Rather, it offers guidance, not “must-do” mandates.

These expanded notions of ITIL’s domain, though benign in intentions, have sometimes created tensions among various communities in the enterprise. Application developers didn’t necessarily appreciate ITIL V2 delving into application management, seeing it to be outside the role of the IT infrastructure and operations staff – the target audience for ITIL guidance from the outset. And enterprise architects may have felt their own Open Group architecture framework (TOGAF) territory was invaded by the V3 Service Strategy book that, despite its excellence, discussed activities outside the traditional scope of IT infrastructure staff.

"ITIL was designed for and is almost exclusively consumed by infrastructure management and operations, and V3 caused some problems,” explains ITIL expert Brian Johnson, who was part of the U.K. government team that originally created the ITIL approach. Johnson has authored many ITIL books and now is Principal Services Architect at CA Technologies. An example, in his opinion, is that the Service Strategy book shouldn’t be in V3 of ITIL. “It talks about the whole issue of designing services from a marketplace perspective. It is a genuinely excellent book that addresses subject matter outside the remit of most in-house IT service providers (and ITIL consumers) and would have been better placed in one of the OGC Programme Management guides.“

The release of ITIL V3.1 in July is aimed at addressing some of the more contentious issues that have arisen, and it takes steps such as placing into better context where ITIL does serve as a best-practice framework and where it does not. In other words, for instance, it acknowledges that it is at the discretion of the organization how portfolio-, project-, or security-management fits with the ITIL framework, if at all. While it is entirely reasonable for ITIL-adherents to have ideas on how to work with other good practices and practitioners of other equally important disciplines, including enterprise architecture, ITIL is not best practice for these disciplines, Johnson says.

That comes as welcome news for many, (enterprise architects not least among them!). Perhaps a lessening of friction among parties may lead to better relationships among enterprise architects, developers and IT infrastructure professionals — relationships that could be quite healthy for enterprise efficiency and productivity, too.

So Happy Together

Enterprise architects, application developers and IT infrastructure staff, for example, may want to put their heads together and revisit ITIL V1 and its Software Lifecycle Support book, as well as the V1 Business Perspective series. (In particular, Johnson recommends the book ‘Understanding and Improving’).

These books, Johnson says, do not claim to offer best practices for development, programming, database design or any of those things. But they do provide guidance for IT operations staff working with those involved in service creation, which of course includes the development organization and the architects charged with setting enterprise standards for removing complexity from application portfolios and enabling business responsiveness. “The books just explained where the different pieces came together,” Johnson says of the various elements that play into the software lifecycle. “Strictly speaking, that’s an Enterprise Architecture view.” And wouldn’t it be a good idea, he suggests, for enterprise architects and IT service professionals to come together at some point in the creation of new services and applications, so that they will effectively run on the infrastructure?

“It’s important to communicate how you can help one another,” Johnson says. Business services as well as IT services are bound to create storage, availability and recovery issues — all IT responsibilities and ITIL disciplines. So, when new programs of work are undertaken, it makes sense for enterprise architects to figure out what all the interfaces are, and make sure all the right people, IT operations included, are consulted at the right time throughout the design process. 

At the same time — given the weight ITIL has long carried in many organizations — enterprise architects, among others, may expect more from ITIL than what it in reality delivers when it comes to creating services. In which case, those expectations should be tempered: V3 didn’t provide a method to go from service strategy to service design.

“Right now, there is a disconnect between what an architect is probably expecting and what is delivered,” Johnson says. ”You don’t ‘design’ services using a catalog, for example. A catalog is where you put things. A catalog might offer reuse capability, it can store blueprints of designs, but it just cannot create new service designs.”

That said, the definition of design is often a moveable feast, Johnson notes, taking us right back to the importance of inter-discipline communications. “An operations manager might consider a new service to be, say, provisioning a server--but from a business perspective that would be an invisible component of a service that the business requires to process insurance claims in a different way. So the design will include inputs from many domain experts—including ITIL experts,” he says.

While ITIL does have a view on enterprise architecture, it is no more or less than a domain opinion on how best to interact with another domain’s best practices . Used incorrectly or as a blunt instrument, Johnson says, ITIL can in fact create more problems than it solves. But, as he also emphasizes, value will result when different parts of the organization come together to review earlier and current ITIL guidelines and come to their own interpretations as a group of how best to utilize them for the benefit of the particular enterprise. “It all comes down to attitude, behavior and culture,” he says, if enterprise silos are to be successfully bridged. “Stop talking and listen to each other.”

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.

About the Expert:

Brian Johnson, CA Technology Services

Brian was part of the U.K. Government team that created the ITIL approach. Working for the U.K.'s Central Computer and Telecom Agency (now part of the Office of Government Commerce), Brian authored many of the ITIL books and designed both the ITIL business perspective series and version two of ITIL. He founded the ITIL user group (itSMF--and is an Honorary Life Vice President). His version one book, Software Lifecycle Support, written with software testing guru Richard Warden covered the roles of IT operations and development in designing IT services, one of the central tenets of the version three ITIL books.

Working with CA Technologies, he helped a major client achieve ISO accreditation for their IT operation. Brian has authored, or co-authored, more than 20 titles on ITIL, project management and related subjects. Putting theory into practice, he led both the first successful government implementation of ITIL best practices at National Savings, as well as one of the first private-sector examples at General Accident.