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.