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!”

What matters most to enterprise architects as private clouds take shape at their organizations? The same issues that always matter: standards, repeatability, governance and structure.

Yet, I would say that all those things matter more than ever with private clouds. They are not, after all, just highly virtualized data centers times 10, and cannot function — as many virtual environments have managed to do — by fitting old and perhaps loose operational processes into a new paradigm. The private cloud is too dynamic, too invested in the concept of constant change, to get by with out-of-date configuration items or less than rigorously controlled change-management processes that only increase risk.

The agility of a private cloud cannot be compromised by lags in delivering IT services that result from poorly documented, automated and orchestrated processes across platforms, applications and IT groups. Private cloud ecosystems must be architected with an eye to controlling everything: how applications fit into the new infrastructure; how resources are automatically reclaimed from discontinued services; how charge-backs are handled in order to avoid overreaching by business units.

Support for moving these principles from paper to private cloud infrastructure has been lacking, however. For the enterprise architect, private-cloud development work has been akin to freehand-sketching of a draft on a vast, blank canvas — a lot of time spent on figuring out which brushes to use and what colors go where.

What is really needed is a detailed “color-by-numbers” kit to bring the complete picture to life. The emergence of the Virtual Computing Environment (VCE) standardized, converged infrastructure is a first step in this direction. It uses prepackaged technologies from Cisco, EMC, VMware and Intel to deliver integrated, modular units of on-demand computing capacity required by enterprise private clouds. The Vblock™ Infrastructure Platform or stack of processing power, storage and virtualization technology provides a solid, highly repeatable and ultra-standardized way of building the new data center, removing a lot of the risk from the process and speeding time to value.

From the enterprise architect’s perspective, Vblock platforms are also a safe bet for interoperability and compatibility when bursting to the public cloud, given the tremendous number of service providers that also use the VCE converged infrastructure.

The Color-by-Numbers Kit Gains More Detail

Vblock Infrastructure Platforms from VCE, in essence, give the enterprise architect the broad outlines of the color-by-numbers picture he or she is creating, as well as a plot for using primary colors to fill in those outlines. But the enterprise architect also needs a seamless way to drop into that picture more fine lines and degrees of shading to optimize the racking, stacking and tuning that VCE enables.

Think, for example, about how manual processes for just about everything — from change and configuration management to app provisioning and security — still account for most of the enterprise’s IT labor and costs. And now think of the opportunity that exists for the enterprise architect to help reduce that overhead by moving to policy-based, model-driven configuration and governance, or by directing the automation of the entire identity lifecycle of users. Think, too, about instituting a structure that enables IT to leverage a catalog of reusable software components in the creation of compute clouds; that directs abstracting applications from their underlying infrastructure to support agility; or that champions an environment where services are charged for by the quantity of allocated resources. 

With service management, service assurance, service automation, virtualization management, capacity management and security solutions from CA Technologies for use with Vblock platforms, enterprise architects can describe a framework for IT and the enterprise that realizes the agility and efficiency of private clouds.

To enable enterprises to achieve greater financial, efficiency and environmental advantages of cloud computing, CA Technologies, with its Vblock platform-certified solutions, initially focuses on ways where self-service automation, orchestration and accounting capabilities are required to deliver a reliable and scalable environment:

• Helping deliver virtual desktop infrastructure (VDI) deployment faster by embedding the common policies and controls required for checking in, checking out, reserving billing; and
• Capacity planning in preparation for migration of Tier 1 enterprise applications to the Vblock platform.

Taken together, the Vblock platform predefined private cloud ecosystems and the ability of CA Technologies to manage these stacks give the enterprise architect not only a full artist’s toolkit, but also the means to readily make use of it. Now that the enterprise architect has the ability to enforce standards, drive repeatability, enable governance and conform to structure, the business gains quicker time to deployment and better time to value, while minimizing risk.

What are you doing with your architecture to speed time to value in your data center or via private cloud? 

CA and VCE are business partners and as part of this relationship, from time to time, engage in joint marketing. No fees or monetary benefits were exchanged between the two in relation to this post. This discussion post is presented for your informational purposes only and is presented, to the extent allowed by applicable law, “as is” without warranty of any kind.

There’s a wide chasm between true enterprise architects and those who hold that title but who are primarily technology enthusiasts. The enthusiast’s passion is impressive, but it isn’t necessarily to the company’s advantage when it comes to paying the price those passions can lead to.

One way to tell what category enterprise architects are in is by the company they keep. If enterprise architects spend most of their time with developers, R&D staff, or other specialized technologists, they’re really enthusiasts. On the other hand, if they divide their time between meeting with development personnel and discussions with the CIO/CTO, the people minding the budgets, the project managers and other business people in the organization, then they’re true enterprise architects.

It’s easy to get caught up in the excitement of new technology, of solving complex problems, defining innovative new approaches and being a visionary for a potentially large number of developers. I know because I’ve done it — unfortunately, at the expense of guarding other factors, such as the costs related to my decisions.

This isn’t to say that a true enterprise architect can’t be enthusiastic about the potential of technology — that is one of the job requirements, after all. But it’s only one of many. Just as an automotive or an aeronautical architect must make safety a priority each and every day, the enterprise architect must make software economics a priority each day. For the sake of the company — and for the sake of his or her job as well.

Architecture + $$$$ = Formal Approach

Executives and managers know how finite resources are, and that there are limits to what can be accomplished in any period of time. That makes the role of the enterprise architect even more valuable, as this person should not only be able to make good design decisions that match the technology to the business problem being solved, but that also reduce the risks of related costs as much as possible.

Consider the various dimensions that exist around building a software product that serves a business need, has value, and represents revenue to the implementor. The responsibilities of the CEO of the company that is building the product include, among other things, meeting shareholders’ financial expectations. The technical staff’s job entails building, deploying and maintaining the software to meet customer expectations. The enterprise architect (and his staff’s) job is to define the technology road map and blueprints for IT staffers to follow in completing their work, and reassure the executives that the resources are being used most efficiently. You need to prove that the direction you are taking makes sense economically – that your efforts will keep costs under control – and won’t expose the business or its shareholders to undue risk, while also driving revenue. 

Yes, you’re in a tough spot, but if you prove yourself to both the business and IT sides of the organization, your worth increases to the point where you become invaluable to the company’s success. Achieving success in this role isn’t based on some quality you’re born with, or luck. It requires skill that is honed through experience and education. Fortunately, there are formal specifications and methodologies to help you reach this level of success.

Economic-Driven Architecture

It’s no surprise that the words budget, and cost appear more than once in the Software Engineering Institute’s (SEI) definition of the term software architecture. In fact, the SEI defines a methodology and practice around an architectural cost-benefit analysis method (CBAM), and it integrates this with its architecture trade-off analysis method (ATAM). This is followed up with a guideline document that shows how these two methodologies can be combined for overall success (technically and economically) in an SEI report on the economic approach to architectural decisions. (You can read the SEI’s discussion of architecture and economics, along with other papers that describe how to measure and apply the proposed economic guidelines for software, here.)

The following diagram is taken directly from the CBAM, and serves to provide context to the enterprise architect’s job and responsibilities:

Figure 1. The SEI CBAM Context

The arrows that point from the architectural strategies of your organization to the key quality parameters these strategies should address (performance, security, usability and so on) extend also to point that the software that results from following these strategies should have real benefit to your organization. What’s also added to this diagram is a large shape that represents the architecture’s associated cost. It may be subtle, but the size of this shape is equal to the size of the shape that represents the overall benefit of the architecture. The goals of the CBAM are to ensure that costs are measured and compared fairly to the technological benefits of your architecture and that the costs are not larger than the benefits.

Conclusions: What’s Your Value?

Businesses make decisions — including those about which employees can’t be sacrificed even when money is tight — based on their employees’ real (and perceived) value. That value is derived from calculations that estimate how much potential revenue can be attributed to the particular employee, minus the cost of employment. Showing that your decisions aren’t only sound technically, but also save the company time, effort and money, will help boost your own value as a key contributor to the company’s financial well-being.

Can you prove your worth that way, and show that you're more than a technology enthusiast? If so, congratulations! You're on the road to being a successful enterprise architect. If not, now’s the time to start making a change.

We’re not that far removed from the U.S. income tax season, and so still pretty close to all the stories about how “creative” people can get when it comes to their deductions or about how they parse out their actual incomes. Well, it turns out that enterprise architects may want to tap into a little financial creativity, too – that is, at least in so far as it relates to funding their projects.

The time is ripe: EA initiatives have suffered both from the economic squeeze and from baggage of recent years, when efforts didn’t always live up to the hype. But the economy is slowly thawing, and EA is by many accounts gaining a new lease on life. Organizations struggling to factor in virtualization, cloud computing, mobility and other shifting IT paradigms are renewing their interest in this practice to help ensure their next IT steps line up seamlessly with business strategy.

Lo and behold, one of the most innovative ideas I’ve heard in awhile about how to fund EA is to follow the good old April 15 revenue model brought to you by your dear friends at the Internal Revenue Service: That is, treat it as a “tax” on projects and operational systems. What this means is that all projects and operational systems pay a fee — a tax — as a percentage of their budgets to support EA initiatives, with the EA efforts and resources serving the entire organization. This tax model can work to eliminate EA silos by encouraging a more democratic execution of EA initiatives across the enterprise. However, it runs the risk of irritating folks who’ve paid the “tax” but feel they’ve gotten nothing in return.

Another idea that’s making the rounds is to fund EA the same way research and development is funded — in that case, either a business unit or the company at large can supply the investment. Viewing EA as R&D clearly designates the practice as strategic, but may tie EA to a requirement for revenue generation in the same way R&D is.

More Traditional Methods Have Their Virtues, and Their Drawbacks

These latest ideas accompany the ones that have been around for awhile. Typically EA projects, and their costs, are considered part of the overall IT budget, and generally follow one of these three models:

1)    The per-project model. In this scenario, every project that would be impacted, or fall within, the scope of the EA initiative would directly fund the initiative. So, for example, a project involving the IT organization’s audit and security initiatives might itself carve out money for the accompanying EA work.

2)    The operations model. In this model, EA is fully funded from the IT operations budget, as an ongoing expense.

3)    The capital model. Here, EA is funded as a capital expense in the initial IT budget, indicating that the EA effort is not an ongoing operational expense, but a one-time only expense (at least for that fiscal year). 

I covered a couple of these common funding scenarios, and their pros and cons, in our Smart Architect slidecast, 7 Steps to Transform Your Enterprise Architecture Practice. You might want to have a closer look at that, and consider while you’re viewing it these further reflections on the funding scenarios’ positive and negative aspects. For example, per-project funding may signify that EA isn’t viewed as a strategic practice because it doesn’t rate an enterprisewide embrace, and it also makes EA completely dependent on others’ whims about how much funding a team should get. If a project head deems EA as not being critical, or if he or she is trying to save money for other initiatives, the project head may simply cut funding to the EA team. On the other hand, per-project models can enable tighter cost controls and reduce scope creep, which actually is a good thing for the EA team, as it can lead to quick and completely tangible wins.

The operational model has benefits largely because it ensures a steady stream of funding, and puts EA in a more strategic, central position to serve the entire organization. With this model, EA teams can focus more easily on architectures that accommodate the entire organization and avoid silo-based EA efforts. On the other hand, funding EA as part of an ongoing operations budget can make EA look like overhead, and we all know what happens when initiatives start to get thought of as overhead. They may (mistakenly) be deemed noncritical and may even get the axe whenever budgets need tightening.

With the capital model, EA is funded as a distinct, capitalized expense from the overall IT budget, and so isn’t dependent on ties to specific projects. Here again, as with the operational model, that puts EA in a more strategic place and opens the door to more enterprisewide efforts. Another plus is that it’s less likely to be seen as overhead. On the other hand, this approach makes EA budgeting more dependent on annual performance, and requires yearly justification and renewal approvals. #

If I had to choose among these traditional funding entrants, I’d opt for the capital model. I think there’s nothing more important than making IT and operational decisions grounded in business, and business success. Performance should be tied to budget allocations; otherwise spending can be for naught, or get out of control. I’ll give one caveat, though. The capital model requires that you have an organization that isn’t bogged down in red tape and committee after committee after committee review. It requires, that is, an organization that is agile and focused.

There are many more pros and cons to each model, and I’m sure there are many more models (feel free to let us know what you’ve seen!). But the takeaway is to think about how your organization handles funding, as the approach can have an impact on EA’s success, and its legacy. While you don’t have control over budgetary decisions, perhaps you can exert some influence by including in your EA proposals not only the recommended budget allotment but the budget model you think works best in your specific circumstances.

One thing that was demonstrated by recent problems in the cloud — notably, the high-profile outage of Amazon’s S3 storage service — is that it’s incumbent on enterprise architects to establish procedures, processes and standards for dealing with cloud service providers.

The fact is, cloud services appeal to a wide array of business people in a variety of business areas, and with a growing number of service providers, there are many places the cloud may be employed in an enterprise. Indeed, in recent surveys even many CIOs admit they don’t know all the cloud services being used in their organizations.

We began talking about the role enterprise architects have in the cloud in blogs such as  Architecting the Cloud: What Workloads Should Move First? and in  Cloud and Mobile Computing: Better Together Of course, CIOs and business leaders clearly are central to establishing Service Level Agreements (SLAs) with cloud providers, but the enterprise architect can be a valuable asset to them by helping to establish a set of cloud services procedures to apply across engagements, for greater standardization, coherence and consistency.

To me, the ultimate lesson from the recent Amazon outage may be to “plan for failure,” as a recent InformationWeek “Global CIO” column put it. However, when it comes to dealing with cloud services and providers, many business managers also need lessons in how to plan for negotiation, plan for implementation, plan for maintenance/upgrade, plan for crisis and plan for end of life.

That’s why a set of cloud service procedures — from inception to completion — should be standard operating procedure (SOP) for most organizations, and the enterprise architect can help generate and disseminate that list. Here are some important points to include:

1. How to negotiate with service providers. Buying software and/or services is different from buying a car, although business unit managers (especially inexperienced ones) may not be aware of the subtleties. A place to start is with an approved list of service providers and a limit to the services that business unit managers can employ (i.e., SaaS, yes; PaaS, no). Enterprise architects can work with the IT team to vet these providers.

2. What to put in — and expect from — an SLA. On this point, enterprise architects should look to incorporate feedback from network managers, who can play an important part in helping to generate this component of a cloud services architecture, as well as their C-level peers.

3. What to do next — that is, first. Define the immediate steps to take after a service outage or other performance problem has occurred. For example, you can enlist automation tools you have purchased to kick in and orchestrate application responses to failures or other changes in the infrastructure.

4. How to handle a data compromise. Observers criticized Sony for being slow in revealing the data compromise of its PlayStation Network. But enterprise architects need to provide guidance about what circumstances require immediate user alerts once a data compromise has occurred. Along with the security, or risk-management team, they can structure best practices around what’s the appropriate time period for full disclosure, and who should make that determination in various cases.

5. What happens if the service provider goes belly up? Who owns any customization done to software, and what about customer/employee/partner data? Enterprise architects can devise a road map for these issues, as well as a pathway for bringing assets back in-house or migrating to another provider with the greatest speed and efficiency.

Even if some of these points may be too fine-grained to incorporate in the wide-scale enterprise architecture, especially for larger organizations, the overall issues need to be explored and codified. Here are some general tips on achieving those ends:

• Call in the lawyers. They can provide the fine points on contract negotiation, as well as boilerplate legalese and even a model contract for compute services.

• One of the major areas of cloud services involves transparency: How much of the provider’s inner workings will be open to your team’s inspection? Redundancy? Security? Disaster recovery? Visiting a service provider’s facilities might be an appropriate first step.

• Make sure cloud services standards and procedures align with other significant architecture standards, such as security and compliance.

• When completed, communicate.  Make sure all levels of the organization are aware that there are standards and procedures for dealing with cloud service providers and that they must be followed. Upper-level executives should reinforce this message.

What cloud services procedures are you attempting to accommodate , either as part of the grand enterprise architecture or in other codifications? Write and let us know. 

Talk to an enterprise architect about the cloud, and you’re likely to hear him or her say that it’s an opportunity to cut future costs. Think of it this way: The enterprise architect sees architecture as a game of chess, with each move setting up future moves. Longevity of solutions also is desirable, since spreading a project’s costs over an extended lifetime increases cost-effectiveness. Therefore, the cloud represents savings in terms of future growth to the architect.

This is precisely what architects mean when they refer to an “elastic architecture,” or the elastic nature of a virtualized server environment hosted in the cloud. Future growth — and savings as that growth takes place — is assured by access to a virtually unlimited pool of hardware and software resources that are used only as needed, avoiding waste at every turn. (Full-service companies, such as CA Technologies, provide elastic cloud solutions with application management services built in.)

Cloud: Scale of Economy

Wait, the economic benefits don’t end there! To the enterprise architect, the savings value goes beyond elasticity. The cloud adds another layer of abstraction and simplicity to the enterprise application environment. As any good enterprise architect knows, abstraction leads to reward, because it removes an otherwise complex set of components from the equation and replaces it with a single, manageable square on a white board.

This square can then be contained and controlled — and further, it can be labeled as someone else’s problem. That someone else is the cloud provider. The cloud fits this square, and this description, perfectly because with it, the enterprise architect can design solutions that are quicker and easier to develop and deploy. And whenever you see quicker, or easier, think $$.

Cloud vendors can offer an enhanced application environment at a reduced price because of the economies of scale. After all, they’re providing comprehensive hosting solutions to a potentially large number of enterprises, and can pass along the savings that come along with this volume. The architect that taps into the scale of the economic savings this represents will save his or her enterprise money with compound returns in the future.

A Rose by Any Other Name

Here’s the twist: Many architects won’t cite “cost savings” verbatim as their driver toward the cloud. Instead, they may characterize it as a drive toward simplicity, allowing them to focus more on the real business solutions they’re tasked to design. But if you probe a little farther into that statement of simplicity, a good enterprise architect will explain how simplicity results in better security, improved performance and quicker application deployment.

I hear cost savings when I read that, don’t you?

Here’s how this played out in real life for me in a recent project I was involved in where key client components were moved to the cloud:

- The number of components installed on the client side was greatly reduced, which simplified the deployment process and reduced the chance for error during download.

- With the bulk of the business logic that once ran at the client site now up in the cloud, performance was improved and made more consistent; no longer was there a reliance upon varying client hardware capabilities to execute.

- Security was greatly improved, and simplified, since the client components that once had to navigate client proxies and other network security provisions were moved up into the cloud, and accessible over standard, and secure, web protocols.

- Management was simplified and outsourced to the cloud provider, and support staff was no longer required to manage issues with client downloads and server access issues.

Can you hear how that adds up to cost-savings now?

In an upcoming blog, I’ll discuss why the enterprise architect should be focused on efficiency and cost in every decision he or she makes.

In the meantime, you may want to explore the cloud economics issue further by reading this blog written by Smart Enterprise Exchange editor and community manager Paula Klein, as well as this article by Doug Bartholomew.