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.

Software engineers, whether programmers, architects, or development team leads, often refer to software design or code as elegant. But can it be outright beautiful? I'm not talking about just its correctness, usefulness, or even its elegance, but instead its overall beauty, which in my opinion encompasses all of the other positive attributes of software architecture.

I fear that people may not look at past software projects with the same sense of the need for preservation that they do for the architecture of structures. If someone were to ask you to provide a list of past software projects that were beautifully architected (besides your own, of course), would you be able to come up with a single one, never mind a list? It would certainly be a difficult task. Part of the problem is that software architecture isn't apparent to the end users of the software itself.

I propose that you should not typically ask the architects or the end-users themselves, but instead ask the people who maintain, administer, and manage the software. This isn’t just a philosophical exercise, by the way – you’re asking about architectural beauty in order to highlight the achievements of your individual architects, expand on their unique ideas and innovations, and have their successful designs replicated within other systems for years to come.

Judgment Day

Examples of people who can judge architectural beauty, for enterprise software, are:

• The folks who handle the deployment of the various components that make up the software system;
• Your datacenter operations people;
• Those who work your help desk.

There may be other types of jobs that people do to maintain your enterprise software systems, specific to your enterprise or your software, but you get the idea.

So I ask you, do you talk with them on a regular basis? Do you ask their opinions of the software that comes their way, or whether there are any specific headaches related to it that they're willing to share? Also, does anyone track problem incidents from their perspective? I'm not talking about bugs and other software errors, but about operations-related issues such as failed attempts to add new users, or other concerns, such as ease of deployment of new software versions to production, resiliency of individual systems, and so on.

True Beauty Is Internal (and Enduring)

It's as important to ask your deployment, operations and other application management staff these questions as it is to ask home or building owners their opinions of the spaces they occupy, as a way to judge the related architecture. With software, the beauty of an architecture is reflected in its lasting nature, which goes beyond a single software system. Since individual systems are so short-lived (before they're updated or replaced with something else), the gauge of software architectural beauty is judged by how it propagates, and becomes replicated in other systems.

If it turns into a template by which future systems are built, it may be beautiful, especially if it's replicated by companies other than your own. But how can you be sure something's worth replicating? By tracking the issues I suggested above, plus a few others:

• Performance, scalability, flexibility, ROI: Those are a given, of course.
• Ease of deployment: Track both how easily and quickly new servers are brought online, and new software is deployed to existing systems.
• Help desk activity: If you don't hear about your users' complaints, it could be because you have a good help desk. Make sure you track all help desk activity to find faults and improvements.
• Provisioning and permissioning: Understand the difficulties involved in bringing new users online, or to give permission to existing users for additional system functionality.
• Data issues: An area too often ignored, data-related issues can account for a great many errors as well as wasted time and lost money. Track your data issues, and find systemic problems and patterns to avoid in the future.
• Application-specific probe-points: Much like hardware engineers build probe-points into their electronic designs, you can carefully analyze your system for areas that are specific to your software to track over time, while in production.

Some tools to use in your quest for beauty include those to help you track and manage issues regarding data availability, cloud-based deployments, individual software components, and other hardware and platform-related issues. Consider the following:

◦ CA Data Management

◦ CA Service Management

◦ CA IT Management

◦ CA Asset Manager

◦ CA Infrastructure Management

◦  oneSIS open-source enterprise management system

◦  Bugzilla, or Mantis open-source defect and enhancement tracking software

Incorporating the use of these systems, or others like them, into your architecture and processes ensures that the beauty in your applications' architecture will shine through.

Fame and Fortune

Everyone knows the names of famous building architects throughout history—Frank Lloyd Wright, Christopher Wren, Michelangelo. I accept that the world at large may never celebrate chief enterprise architects to the same degree. But at least within the organization it’s important to highlight the achievements not only of your enterprise architecture, but of the individual architects involved. As you discover patterns in your systems that have led to great success, you’ll want to publish them internally for others to replicate in their own systems, and for future architects within your organization to learn from. When you do that, don't forget to publicly commend the architects themselves, since achievement is often quite contagious.

The first company I worked for believed in this, and good design was highlighted and shared across teams. This proved very fruitful, as the result was a long history of successful software products with few, if any, canceled products or releases. The key, as in most things in life, was good communication through tools, processes, techniques, and quite frankly, culture.

As the enterprise architect in your organization, you have direct control over all of these attributes, and as a result, over the success of your software systems. What do you find beautiful in software architecture? Is it its reuse through your organization, its innovative qualities or other aspects, such as its flexibility? Share your thoughts with us.

A lot of attention in the architecture process goes into translating business requirements to technology, specifying and documenting the resulting systems, and calculating the economics involved. Often, architecture success is judged after software is built, which can be years later.

But the goal should be to automate the assessment and approval of the architecture artifacts before the software is built. In other words, what we really need are ways to quickly measure and assess our architecture specs to be sure the resulting software will meet customer needs, be built at or below budget, and be secure, on time, and extensible for the future.

There's certainly a lot of work to do there, and this comes after the hard work of defining the architecture is complete, but before the software systems are complete.

Measure for Success

You know the saying, “measure twice, cut once?” Sometimes I measure three times, especially if a mistake means destroying something valuable and losing money, or wasting time or effort. Our architecture processes deserve added scrutiny even after the deliverables are complete, just to ensure that development doesn't commit to an endeavor only to have to make costly adjustments along the way because of design problems that could have been easily resolved early on.

To do this, I propose the following metrics and suggest how they should be applied. Some of these metrics are based on the Software Engineering Institute's work on architecture:

• Performance: How do you measure performance, which by itself is a vague statement? Is it a measurement of transactions per second (throughput)? Maximum transaction latency and overall predictability (real time)? Or other factors, such as messages per second, queries per second, or searches per second (IO)? Most likely, you'll need to measure your architecture against at least a subset, if not all, of these.
• Cost: Measure the ratio of anticipated costs to actual costs. Some things to note: costs that were lower than expected;
• Return on investment: Regardless of cost (high or low), it's important to measure the returns from past architectural decisions.
• Skill set: Are the technologies, tools and techniques outlined in the architecture beyond the skill set of the existing IT and development teams? If so, is it better to revise the architecture, or include a training program for those involved? You'll need to rate your team's abilities in many areas of technology.
• Experience: Having a skill set through training is one thing, but experience building real software using those skills is another. How do you rate the experience level of the development team(s) implementing the architecture? (While skill set and experience clearly target development, they're on the list because architecture dictates these requirements.)
• Communication clarity: How clearly is the architecture communicated? Does documentation exist? Are the documents easily accessible? Do you welcome feedback? Do you use standard illustration techniques and methodologies?
• Coordination: How do you rate the coordination of activities among the groups involved, from architecture delivery, to development, test and deployment? You should strive to define an organizational coordination model with metrics around its effectiveness.
• Learning: Measure how effective your organization is in using the information you've learned from past projects to improve future projects. This may seem a bit cyclical (the metrics include metrics for how effective they are), but they're the result of the measurement activities, outlined below.

• Reviews: Just as software code reviews help developers ensure quality early in the development process, architectural reviews begun early help ensure a favorable outcome. To execute the reviews, I propose small teams (four people or fewer), where individuals focus on a dedicated part of the architecture in review, or a portion of the architecture document. At this phase, don’t pay attention to spelling, grammar or other editing activities. Instead, focus on the architectural content itself, and identify what can be improved, added or expanded on.
• Analytics: One organization I've worked with has implemented an elaborate set of analytics, through which it mines data from past and current projects. The analytics extract details, such as common results that correlate to factors that were not obviously related, and this data is used to ensure future project success. For instance, it was found that every project that came in under budget had a data architecture that specified the use of stored procedures. The choice of database vendor was found to have little to no effect in this respect.
• Debriefings: This is similar to the reviews suggested above, but done after key software is released. The goal is to measure the outcome of the development process (i.e., successes, problems, key knowledge gained, and so on), and reconcile these against the architecture:

               -- Identify areas of the architecture that led to particularly strong development success.

               -- Detect areas that could have been improved or modified early on to avoid issues.

               -- Identify ways to remediate issues for the future.    

               -- Extend or expand on the things that worked well.

In any type of review, you want to find areas of improvement, but you also want to identify what works particularly well, and build from there. Never, by the way, use these reviews to focus on the individual performance of team members. Doing so could hinder the willingness of everyone on the team to participate fully in the architecture review and measurement process.

In conclusion, I say: “Measure often, code once!”