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.

Back in August 2010, Smart Enterprise Exchange featured David Buckholtz, Vice President and Divisional CIO for Enterprise and Corporate Technology at Sony Pictures Entertainment, in a story about Platform-as-a-Service adoption in the enterprise. My reason for mentioning this piece today — besides to note the insightful nature of the article itself — is that Buckholtz has something in common with readers of this blog: His résumé includes tenure as Chief Architect at GXS (formerly part of General Electric), and as a Senior Consultant and Architect at IBM.

How typical is it for a very senior and seasoned enterprise architect to become CIO, I wondered? In some respects, it seems a natural trajectory: It’s likely that you’re already located within an IT group, so expectations of rising within the organization seem well in line.

In fact, the challenge may lie with how the enterprise or the IT organization itself views the role of enterprise architect. Ideally, the enterprise architect function is seen (much like the CIO function) as a critical component of aligning business and IT. In that case, the EA team is deputized and resourced to marry organizational processes with technology that will deliver value to the enterprise and its customers.

If that’s the type of organization you’re in, you may well be in good shape to shoot for the job of CIO — either in the same company or somewhere else that subscribes to the same philosophy and appreciates the results that philosophy produces for the business .

If your company has more of a technical view of the EA function, however, and expects architects to get by more on the fend-for-yourself model, then perhaps some detours are in order to reach the goal of CIO. One choice might be a lateral move to an EA position in a company that has a more-encompassing vision, of course. Or you might consider exploring other avenues — within or outside your current employer — to building a resume that showcases the fact that you’re far more than a repository of technical expertise. After all, that’s what companies (thankfully) have come to expect from their CIOs.

Can your business talents be better nurtured and exposed — and will your management expertise grow — if you bring them and your tech prowess to other areas of the enterprise? For example, you may thrive in a line-of-business domain where, as either a senior-level business analyst or a business manager, you can directly contribute to sales and operational wins rather than setting the stage that leads to them.

Another option is to join a consultancy or software solutions business that may provide an opportunity to not only provide technology leadership internally, but also to be part of a development and management team that has a role in the external sales cycle.

What are your thoughts about moving into a CIO position? What would you tell the search committee about why you are the right hire for the position? Heck, is it something you even want, and if so, what’s your game plan for getting there?

Back in August 2010, Smart Enterprise Exchange featured David Buckholtz, Vice President and Divisional CIO for Enterprise and Corporate Technology at Sony Pictures Entertainment, in a story about Platform-as-a-Service adoption in the enterprise. My reason for mentioning this piece today — besides to note the insightful nature of the article itself — is that Buckholtz has something in common with readers of this blog: His résumé includes tenure as Chief Architect at GXS (formerly part of General Electric), and as a Senior Consultant and Architect at IBM.

How typical is it for a very senior and seasoned enterprise architect to become CIO, I wondered? In some respects, it seems a natural trajectory: It’s likely that you’re already located within an IT group, so expectations of rising within the organization seem well in line.

In fact, the challenge may lie with how the enterprise or the IT organization itself views the role of enterprise architect. Ideally, the enterprise architect function is seen (much like the CIO function) as a critical component of aligning business and IT. In that case, the EA team is deputized and resourced to marry organizational processes with technology that will deliver value to the enterprise and its customers.

If that’s the type of organization you’re in, you may well be in good shape to shoot for the job of CIO — either in the same company or somewhere else that subscribes to the same philosophy and appreciates the results that philosophy produces for the business .

If your company has more of a technical view of the EA function, however, and expects architects to get by more on the fend-for-yourself model, then perhaps some detours are in order to reach the goal of CIO. One choice might be a lateral move to an EA position in a company that has a more-encompassing vision, of course. Or you might consider exploring other avenues — within or outside your current employer — to building a resume that showcases the fact that you’re far more than a repository of technical expertise. After all, that’s what companies (thankfully) have come to expect from their CIOs.

Can your business talents be better nurtured and exposed — and will your management expertise grow — if you bring them and your tech prowess to other areas of the enterprise? For example, you may thrive in a line-of-business domain where, as either a senior-level business analyst or a business manager, you can directly contribute to sales and operational wins rather than setting the stage that leads to them.

Another option is to join a consultancy or software solutions business that may provide an opportunity to not only provide technology leadership internally, but also to be part of a development and management team that has a role in the external sales cycle.

What are your thoughts about moving into a CIO position? What would you tell the search committee about why you are the right hire for the position? Heck, is it something you even want, and if so, what’s your game plan for getting there?

Where do Enterprise Architecture Management Suite (EAMS) tools fall short and where do they shine? I’d like to share with you some of the takeaways I gleaned from reading a recent report from Forrester Research entitled, “The Forrester Wave: Enterprise Architecture Management Suites, Q2 2011,” which evaluates 10 EAMS vendors.

Spoiler alert: Collaboration isn’t a strong spot.

Let’s focus on the shine first. On many levels, EAMS tools are amped-up enterprise architecture (EA) tools. But there’s much more to them, as well. A good comparison might be to think of moving from a network monitoring tool to an enterprise management system that is capable of monitoring and managing networks, systems and applications all together. As for the EAMS tools, Forrester points to the addition of new IT planning and governance, risk and compliance capabilities, as part of the evolution,  as well as the ability to handle not only EA data, processes and organizational models but also EA budgets, strategies, risk and other information categories. The tools also include new capabilities such as automated data-quality checking and advanced analytics, including system or throughput simulations, according to Forrester.

Even more interesting: The research consultancy proposes that an EAMS fits squarely in the center of IT management, giving the idea some legitimacy by noting that EAMS solutions are starting to support non-EA group partners. For example, they are becoming go-to suites for CIOs, project managers, development and operations managers, risk managers, IT procurement and others. Another point: EAMS tool repositories can become central stores of strategic information about both IT and the business.

I won’t go into the specifics of each of the 10 tools in the report. (Forrester clients can access the report here to explore that in greater depth, and others can read the executive summary.) But suffice it to say that the analyst firm sees these as the leaders of the pack. While they all impress in some way, customers still find themselves adopting more than one EAMS to fill some gaps, however.

And here’s a gap that none completely fill: Enhancing collaboration among multiple parties. These include stakeholders that enterprise architects must work with in planning, modeling, designing and implementing an architecture for the organization. That’s very surprising. We’ve got to go beyond ineffective collaboration methods, such as one recently described to me: Using virtual whiteboards to draw and capture some of the enterprise architects’ work. Moreover, I have been told by enterprise architects that many teams also still put all their knowledge into old-fashioned word processing documents … pages and pages of them!

Features such as wikis, instant collaboration, discussion forums, tagging and those virtual whiteboards are included as part of some of the toolsets, but they’re not really enough to help EA teams maintain quality content in a sustainable manner, according to Forrester. That said, the analyst firm sees some signs of positive change, with a few vendors experimenting with social computing capabilities to go beyond the old check-in/check-out document collaboration found in most repositories and knowledge management applications.

But vendors shouldn’t take all the blame. Even when collaborative functions and tools are written into apps,suites and systems, there’s a good chance that half of them are never used, a conclusion I’ve come to based on discussions I’ve had with enterprise architects. That’s especially true for busy enterprise architects, many of whom have risen from the solitary ranks of software programming. Forrester also adds that, “EA stakeholders are not naturally inclined to use an EA tool to share their knowledge for the benefit of only enterprise architects.” Forrester recommends that vendors “add metrics to measure value and reward contributors to instigate a virtuous circle — and, consequently, sustainability.”

Clearly, it’s time for collaboration to play a greater role in EA. It must support the enterprise goals, business processes and information, organizational structure and culture, and IT systems and applications. And there are a lot of stakeholders who need to be in the loop:  CIOs, IT managers, information security managers, risk analysts, business managers, IT developers, even CTOs, CFOs and yes, CEOs. Ensuring that all the components and the stakeholders are a part of the EA process takes nothing less than bona fide   collaboration — across the organization, within the process, and embedded in the EA tools used along the way.