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.