Recently, I’ve been following some discussions in the Enterprise Architecture community that revolve around the issue of where the function of the Enterprise Architect sits within the business — and indeed, how the role distinguishes itself from the work for which the CIO or CTO is responsible. 

These discussions can become very intense, which I think points primarily to the passion and commitment of those in the field about how they know they can help their businesses, and perhaps also to some frustrations about whether that’s as well-understood by those outside the profession. For example, from what I’ve seen, it looks to be the case that enterprise architecture typically emerges as a group within IT, often as more of a technical architecture program in its early stages, and so enterprise architects generally find themselves living within that reporting structure. But more than one has complained that such a structure actually can present some obstacles to fulfilling goals — that without having reporting responsibility directly to the CEO, their EA efforts wind up isolated and their ability to actually improve the implementation and execution of business strategy is seriously at risk.

But even if that’s the case, it’s not likely that there will be any immediate, large-scale change in what appears to be the reporting status quo. So, perhaps the bigger question is how to leverage working within the IT organization without letting organizational structures imperil objectives. Here, some advice I got from Debra Wilcox, Senior Analyst at Info-Tech Research, may come in handy. It is very true, she says, that one needs support from senior management — including the CEO — for enterprise architecture programs and their goals, so that their value is recognized and that straying off the path (without very good cause for exception) is discouraged. Enterprise architects can help the CIOs to whom they report increase their knowledge of what enterprise architecture efforts – viewed holistically beyond technical architectures per se – can bring to the table.

Such efforts contribute to what is really needed for enterprise architecture to succeed, and that is fully implementing its governance aspect through architecture review boards (ARB). “An ARB is a body [that will] look at every project to be done in the organization, significant business or technical projects, and examine the artifacts and goals of those projects to make sure they maintain the integrity of the architecture,” Wilcox explains. There’s regular interaction via this mechanism with organizational strategy and the senior management that defines it, with project objectives and the project and portfolio managers directing them, and of course with the CIO, CTO and representatives from the other reference architectures to ensure that things stay in line. (BTW, also worth checking out this Info-Tech research paper here for developing Enterprise Architecture to drive competitive advantage).

But wait, some say — isn’t the chief architect the new CIO (or perhaps CTO) if everything is working as planned — that is, laying out the rules and foundation within which IT will have to execute? That’s an intriguing thought, but is it a practical one? IT organizations have developed distinct structures over the years, the same as any other group (marketing, finance, etc.), and structures don’t come unglued very easily. In some other industries, like telecom, the CTO might actually be charged with delivering technical services to customers rather than managing the telco’s infrastructure itself, Wilcox says. And in organizations that are large enough, as is often the case in the finance sector, CIOs and CTOs usually have equal footing, with the former responsible for applications and the latter for infrastructure, she says.

And besides, whatever the breakdown, it seems as if there’s enough work for everyone to do as is. “The CIO and CTO set the strategy for their parts of the IT organization, whereas for the operational functioning of those areas, the enterprise architect ensures the fit of these strategies within the architectural framework,” she says. “The enterprise architect is responsible for more than ensuring that just the technical architecture is maintained or that the integrity of it is kept pure. We are also talking about systems, applications, data and security, and business processes.”

How does the role of enterprise architect play out in your organization? Let us know what’s working and what isn’t in your own reporting structure and its impact on fulfilling initiatives.

How are enterprise architects going to enable the business agility that is so critical to enterprises today, as they seek to stare down growing global competition, and harness opportunities to prevail in new markets? The way forward is to tighten up adherence to five critical principles that always have guided — or at least, should have guided — enterprise architecture (EA) efforts. Slackening the reins may seem to be the way to get moving faster, but trust me — that’s only a temporary speed burst. It won’t set you up for the long haul.

So, let’s look with a fresh eye at some of the key steps to help you soundly respond to growing pressures.

Improve the Business Case

Often the best, and quickest, way to meet business needs is to more clearly define those needs in the first place. Spending a little more time up front to better define and communicate the business requirements behind the architecture will result in a more concise solution, and even greater time savings at each step along the way.

Here, the principles to follow are not unlike those your CIO must adopt to build a business case for any tech investment. A good primer to read is featured here in Smart Enterprise Exchange. Joe Peppard, Professor of Information Systems at the Cranfield University School of Management, explains the importance of improving the process used to build a business case — and doing so makes as much sense for the enterprise architect as it does for the CIO. After all, if the business case is weak or lacking, the architecture may be incomplete.

An effective process is one that involves a number of factors. For example, a complete cost/benefit analysis outlines all of the benefits to each business goal or need, remembering that these often can be more than monetary returns.

Another “must” is thoroughly examining the costs and risks associated with each business goal. Also, remember to involve parties ranging from business analysts to key development managers, as their feedback can result in a more refined business-needs analysis. At the same time, make sure to leave room for contrarian views that can be a spur to innovation and better ROI.

Improve Communication

IT architecture has little value if it cannot be thoroughly and clearly communicated to business and IT partners.

So you’ll need to:

• Document the architecture clearly using standard methodologies and guidelines for the areas you’re architecting. Use Unified Modeling Language (UML), the Open Group’s service-oriented architecture (SOA) ontology, or other methods such as Martin Fowler’s patterns for enterprise architecture (EA) (see Patterns of Enterprise Application Architecture, Addison-Wesley, 2002). It’s fine to combine methodologies, but you should strive for consistency.
• Allow for two-way communication. Avoid dictating to others what needs to be done, and how. Instead, create a culture and process that’s open to all opinions.
• Create working groups for key areas, involving all stakeholders in these groups, led by experts.
• Iterate the architecture through open discussion with the business on one side, and development on the other.  

Following these guidelines will result in a living, evolving architecture strategy that moves quickly to meet the ever-changing business and technology landscapes.

Ensure End-to-End Accountability

An enterprise architect and his/her vision can quickly become irrelevant if he or she is not involved in the end product. Accountability is key for success at all levels and has the following benefits:

• It ensures that the architectural vision is carried through from definition to implementation.
• It ensures buy-in along the participant chain, through to development and quality assurance.
• It creates architecture advocates throughout the organization, increasing the number of people who believe in and communicate the overall vision.
• It helps the enterprise architect and CTO put their foot down on silos and “out-of-band” development (otherwise known as skunk works).

Being involved in the development and deployment of the software the architecture defines is the way to ensure that the solution evolves rapidly, and remains relevant to the business. 

Improve Process Measurement

The architecture process should be constantly improved via a feedback loop. Past business technology investments should directly indicate the effectiveness of your architecture vision. To ensure this from the beginning, create key quality parameters to measure and analyze the effectiveness of your architecture each step of the way The Open Group's Architecture Review Checklist, for instance, can be a starting point. It covers questions about general architecture issues, as well as specific items, such as application server technology.

Gauge success of your architecture’s implementation by reviewing :

• Reliability and availability: Did the resulting system have failover and redundancy designed-in?
• Security: Were there any security issues in production that can be traced back to the architecture?
• Modifiability/extensibility/portability: Over time, were development teams able to easily and cheaply extend the system without overhauling or abandoning the original architecture principles?
• Interoperability: Did you design for the integration with future technologies, systems, and data?

If there were deficiencies in your enterprise applications that can be traced back to flaws or holes in the architecture, defining processes to ensure that future architecture work doesn't repeat the same mistakes will help to optimize those areas in the future.

Improve Your Digital Literacy

No one can be expected to know or remember the details of every discipline in a growing world of technology. You should, however, be able to locate, organize and communicate relevant pieces of information quickly and concisely using technology itself as a medium. This involves using hardware (i.e., desktop and mobile devices), as well as software to gather and index the appropriate information. 

Do this correctly, and you can expect to: 

• Stay in front of emerging technology, not just the hot topics of the day.
• Understand what has and hasn’t worked for other companies.
• Remain a thought leader within the organization. 
• Have up-to-date knowledge of costs related to hardware and software deployment as part of an architecture (i.e., basic hardware costs, consulting rates, hosting fees, average ROI for investment in particular areas such as integration, SOA, cloud and so on.)   

I’m going to say it: When it comes to enterprise architecture, be the turtle, not the hare. Take the time to do things right from the start, and the race is yours to win.

I’d love to hear your thoughts about whether such principles have guided and continue to guide your own efforts. Please feel free to share your comments, ideas and experiences with me and your fellow enterprise architects here. See you next week!

Eric Bruno is founder and Principal, Allure Technology Inc., which provides enterprises with online business solutions that leverage Internet technologies and approaches that combine simplicity, rich user interfaces, and service-oriented architectures. Eric also is an expert in full lifecycle, large-scale software architecture, design and development for client/server, highly distributed, multitiered Web, real-time and transactional software development environments. He has worked on large-scale systems, and served as technical advisor, chief architect and development team lead on numerous projects in industries including financial services.

A few weeks ago, Editor and Community Manager Paula Klein wrote here that you could expect to see some new interest groups surface on Smart Enterprise Exchange this year. Making good on that promise, this week I’m happy to be part of the debut of new, exclusive resources for the enterprise architect community. Smart Architect is a group we have created to enumerate, explore and engage with you on the many issues enterprise architects face as they strive to bring greater agility to the business.

Those issues can be pretty monumental, I know. Enterprises have accumulated innumerable legacy business processes and stand-alone services in silo applications that often are linked only by point-to-point integrations. On top of that, the frameworks, reference models and other forms of documentation that have been the traditional outcomes of enterprise architecture (EA) were likely to be treated tactically instead of strategically.

The result of such past portfolio practices? IT organizations’ budgets now stagger under the weight of operational expenses that result from maintaining stove-piped systems, even as IT leaders face new pressures to embrace modern design paradigms — like the cloud — that promise to accelerate business opportunities.

The good news, I think, is that there’s never been a better time for enterprise architects to demonstrate that their discipline can — and should — have strong application to a dynamic business strategy. Today, EA skills are firmly focused on building organic plans to deliver adaptable business capabilities for the organization. This work should prepare the enterprise to reduce IT complexity so that the business can function with efficiency and agility. Those two features are critical today when business-adoption cycles are fast-paced; when the cost-lowering proposition of reusable business services is increasingly critical; and when a consistent and logical view of exploding enterprise data sets matter — as it undeniably does — to help inform corporate next-steps.

All of this sets the stage for your new Smart Enterprise Exchange group. In the coming months, you’ll find informative articles featuring real-world insight from your peers about how they’re forming their EA strategies and preparing for new challenges. You’ll find slide-casts to help you lead your EA modernization efforts. We’ll also feature blogs by expert architects on timely topics, from making way for cloud services to maximizing service-oriented architecture (SOA) returns.

Above all, we hope you’ll join this group, offer comments and actively participate in its content. I’m looking forward to making your voice a part of our vision. Please feel free to contact me with your ideas, comment on my blog, or maybe even start a discussion thread of your own. Thanks!