Analogies abound in software architecture and development. From bricklaying to skyscraper construction, I think I’ve heard them all. Frankly, they can get a little tired. That said, there are two analogies that come from the automotive industry that I reference on a daily basis: road maps and dashboards. While road maps are often associated with software release plans, and dashboards with software administration, both have helped me in my architecture work.

In my experience, most enterprise architects don’t follow a well-defined process, don’t always produce the proper artifacts, and don’t follow their projects through to customer delivery. On the one hand, this is understandable, as tracking all the existing development while planning for future business and technology needs is overwhelming. However, it’s possible to track them at least to some degree, and this is where the proper use of road mapping (to ensure a proper project progression) and dashboards (to maintain a 30,000-foot view of all development) have been proven to help.

Road Maps: The Enterprise Architect’s Guide to the Galaxy

If hitchhikers can have a guide to the galaxy, why not enterprise architects? Wikipedia describes a technology road map as a plan that matches short- and long-term goals with technology solutions to meet those goals. A good road map helps teams to agree on a direction, predict future outcomes and coordinate all processes involved.

The road-mapping process I’ve found useful includes the following phases (see Figure 1 below):

1. Planning
2. Design
3. Development
4. Debriefing

In the planning phase, the business team and the architects define the conditions for the project (i.e., customer needs, revenue goals, time frames and so on), determine who will fund and who will lead the effort, and finally, define the scope of the project. In terms of scope, it’s often just as important to define what not to do in the project. For example, definitions can mandate that you’ll adhere to the 80/20 rule to ensure budgets aren’t blown, that you will support just one mobile platform rather than use a framework that works across all of them, or that you’ll dedicate only a subset of your team for a limited amount of time for a pilot program. Overall, this phase defines the vision for the development effort.

In the design phase, the EA takes the lead and matches the business goals with technology choices, using the artifacts from the planning phase. This includes analyzing existing systems, products and development teams, and determining future needs (i.e., hiring new talent). The important artifact from this phase is an architectural road-map report that outlines the technology choices made, maps those choices back to decisions from the planning phase, provides alternative choices and takes problems into account along the way (a.k.a. Plan B).

The development and debriefing phases might seem like a post architecture activity, but as I’ve stressed in past blogs, such as this one and this one, the enterprise architect must be involved here as well. This involves continuous tracking of the product development back to the previous two phases, making alternative decisions (according to the road map) where needed, and executing on Plan B as a contingency. Debriefing generally occurs once development is wrapped up, and involves measuring the end result against the original vision, and using those results to refine the process for future development efforts.

Figure 1 - Road mapping for the enterprise architect. Illo credit: Eric Bruno

The Dashboard

A road map is useless, however, unless you know where you are, and where you’re headed. When kept up to date, a project dashboard helps the enterprise architect track a project instantly. Products such as CA's Clarity PPM help you build road maps to track and manage an entire project's lifecycle, and also include project views akin to dashboards.

In a large organization with multiple ongoing projects, dashboards are an invaluable tool, and help track the following:

For the overall business:

• Determine business needs:
• Overall health
• Growth areas (expanding existing business)
• Greenfield (new areas of business)
• Track ongoing projects
• Track R&D

For individual projects:

• Track customer requests
• Optimize architecture
• Track bugs and defects

Below is a sample mockup dashboard I created:

Some tips as you create your own are to:

• Keep it all on one slide;
• Include green/yellow/red status indicators for major areas (usually business, tech, and operations). Although there are only three colors here, the truth is this usually expands to multiple colors to account for all major areas;
• Include a summary Gantt chart of up-to-date critical scheduling, customer requests, and bugs, updated weekly (the one in the sample above is from Wikipedia);
• Include an overview architecture diagram so that you can see the data sets, major systems, and client impact all in one view.

As you can see, the dashboards get quite sophisticated even at one page, and are extremely useful when you're tracking lots of systems. Any more than one page and it's overwhelming when multiplied by the number of active projects the EA is or was part of.

It’s no accident that the elements tracked in the dashboards map back to the software road-mapping phases outlined above. I’ve found that using both tools together helps the enterprise architect maintain the unique position of understanding both the business and technology factors for problem-solving in the enterprise.  What dashboards and road maps are you using? 

You know it and I know it: Most large organizations suffer from silos, with duplicate software projects in active development. The reasons for this vary — a political power-play, an accident, a belief that it's easier to reinvent the wheel than drive someone else’s car.

But the results, as every enterprise architect knows, are the same: Duplication is costly, and ultimately it eats into the organization’s ability to function as an agile enterprise — that is, one that can freely and spontaneously exchange information as a whole, and where new initiatives are taken on by many people working collectively, instead of only a few working in isolation.

How to wrestle this problem to the ground? I suggest thinking in terms of the federated architecture pattern, an approach that focuses on software, processes and developer behavior. This approach leads to a more agile organization, as it fosters interoperability between lines of business and information sharing. John Zachman, creator of the Zachman Framework for Enterprise Architecture, has positioned this approach as a practical way to employ architectural concepts in complex, multi-unit enterprises. And he has noted that its success requires someone (YOU) figuring out and actually creating and managing what is to be federated — i.e., that which is to be centralized, optimized, integrated and reused by the overall enterprise. (You may want to read Smart Architect’s interview with John Zachman on recent changes to his framework here.)

Building on Zachman’s definition, federated architecture is more than a fancy term to describe an enterprise-wide approach to software. It's a model to share concerns across the enterprise, and to identify common business problems, infrastructure requirements, development efforts and data needs. It requires, in effect, that you build a system that encompasses the entire organization, so that the business is able to adapt to changes in the market more quickly and efficiently, and in a much more cost-effective manner.

As Fig. 1 shows, a federated architecture solution provides the platform to align disparate systems, data sets, other internal and external cloud-based systems, legacy systems, and infrastructure, all via an organization-wide taxonomy. From the purely organizational perspective, this is a difficult task: You need to align the business, the data owners and all stakeholders, the corporate IT strategy, and all of development. And if that weren't difficult enough, there are technical hurdles beyond the norm.

Indirectly related to this is a means to perform communication and integration across the components: Complex event processing (CEP). CEP involves designing your systems to respond to events that occur across all layers of the organization's IT systems. CEP, which in a federated architecture goes way beyond plain-vanilla middleware, becomes a driving force of systems integration and higher operational intelligence, and as such requires corporate wide buy-in and cooperation. Successfully accomplished, the result is a unified architecture, and a common development approach, for all of the systems in the enterprise — no more silos.

Integrating this into the cloud also ties into everything we’ve discussed here over the past year: further reducing costs, increasing efficiency, and raising overall system quality and uptime. (For more on those issues, see, for starters, Time to Revisit Your Cloud Strategy, Architecting the Cloud: Which Workloads Should Move First, or A Technical Perspective On Which Workloads Should Move to the Cloud.)  It also leads to that elusive agile enterprise, where individual components within the architecture — and the people involved — are part of a larger system, one where changes and improvements affect the organization as a whole, with benefits shared. 

Additionally, the federated approach helps to achieve operational independence: Developers for one part of the system can help (or even take over) when emergencies arise in other parts. Examples include software failures, architectural deficiencies and changing requirements that demand additional expertise. Being able to quickly find others within the organization to plug in and help in these situations is a big win. This is a key value that’s lost in the “silo approach.”

For the past year, I’ve been involved in a project where a set of disparate financial systems are being integrated into a single federated portal. As the system brings together elements of trade execution and supporting analytics, the problems have been wide and varied, from normalizing technology selections, to ensuring data-access rights, to meeting latency requirements.

In an upcoming blog, we’ll explore an architectural solution for a federated system based on this real-world experience. Your own federated systems will vary, and of course they don’t need to be a Web portal solution specifically for these lessons to apply. Regardless of what you’re building or integrating, you’ll face the struggles of coordinating numerous stakeholders across the organization, getting them to agree on an architectural direction, aligning their schedules and deployment plans to one another, and truly implementing the systems according to the agreed-upon plan.

In the meantime, let us know if you have an example of how you have implemented a federated architecture to drive agility – and how you did it. 

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

Any organization that’s been around for any length of time — be it 10 years or 10 decades — inevitably confronts change of some fairly significant magnitude. Such is the situation at the IT-ISAC (Information Technology - Information Sharing and Analysis Center), a nonprofit corporation that since 2001 has focused on cyber vulnerability management and on cooperating with national and homeland security efforts to strengthen critical IT infrastructure.

Having had the honor of both belonging to this group since its inception and more recently of being elected its president, I now also have the privilege of helping to reboot IT-ISAC for the next decade. That’s a job that will call on enterprise architecture skill sets as much it will on security and communications expertise.

Let me explain a little about “what” is changing and the “why” behind it. I’ll start with the latter. It remains important, of course, to understand and address product vulnerabilities. But that’s also a difficult prospect at a cross-organizational collaborative level, considering the risks of disclosure before solutions are available. Not only that, but product vulnerability is just one concern in a world of threats that also includes malware, criminal activity, exploits and other attacks on internal IT environments and the customers they support. Changes in IT service delivery and IT service consumption, including a growing array of mobilized apps, add to corporate risk profiles. And, as cloud computing grows and creates infrastructure vendors from some unexpected sources, so too do the opportunities for threats that may have an impact on these services and their users.

Second, while national infrastructure security remains a focus for IT-ISAC, today organizations are interconnected by their reliance on technologies without regard to national borders. We can’t ignore that.

In sum, the threat has become more complex while vulnerability disclosure and management processes have become more mature. This is propelling the IT-ISAC to refocus on threats to the cyber infrastructure and individual networks:

• Threats to one entity generally are threats to all, and the net of discussion must widen to encompass more participants in individual companies and more international companies with operations across the globe. To address this, we are creating specific communities of interest from the member population at large so that they can more rapidly share and analyze pertinent threats and act to contain them.
• A more globally encompassing IT-ISAC also will take steps to ensure that, even as industry-related information will be free to cross national borders, anything related to national security interests will be appropriately controlled.

Enterprise Architecture Practices Will Help Drive Change at  the IT-ISAC

In other words, we are designing, building, and running a new IT-ISAC. We can talk for hours about what we want the next decade to be, but to effect meaningful change with the highest probable outcome of success requires planning that change and creating mechanisms to enable it. And isn’t the essence of architecture to understand the mission’s larger goals and to build a phased plan to get there — a plan that supports repeatable change as necessary, based on processes and standardized methodologies?

I’m pleased to say there’s great support from the IT-ISAC board for the direction we’re heading. I’m proud to be affiliated with such a luminous group of leaders, which includes some of the most recognized CIOs in the industry. Together we are looking to enhance the strong bonds that already exist among the organization’s members by creating new connections and adding even greater value. As I continue to meet with all our member companies, I look forward to hearing their thoughts on achieving our goals — and to using what I know of enterprise architecture practices to help deliver those outcomes.

I came across two reports in the same day with very different outlooks on enterprise architecture in the U.S. federal government — one with high expectations, and one with some chastened hopes.

Since I always like to start with the bad news, on the theory that a real downer following an adrenaline rush can’t be a good thing for the heart, let’s turn first to a recent report by Stanley B. Gaver of Technology Matters Inc. Entitled “Why Doesn’t the Federal Enterprise Architecture Work?" and available at this blog, the piece was written late last year and has been four years in the making. It is based on research as well as observations about enterprise architecture at six U.S. government agencies. Apparently, the work wasn’t easy for Gaver to write, since he himself believes in EA as a way to correct the duplication and redundancy he saw as a federal IT worker for 30 years.

So, what’s wrong with federal EA practices? Gaver points, as reflecting his own work, to an October 2010 Federal CIO Council report citing concerns about the future of federal EA programs which, the report said, are still bedeviled by issues such as a lack of shared understanding and confusion over where EA resides. From there, he goes on to enumerate his specific concerns, including:

• Using the term FEA (Federal Enterprise Architecture) models has created massive confusion. Referring to them as such blurs understanding of a simple idea of having five standard taxonomies to categorize investments, performance measures, and IT resources uniformly across the federal government. Additionally, further confusion resulted because few actually knew exactly how the FEA reference models fit into and related to the entire Federal Enterprise Architecture program or that the reference models are not the same as the FEA itself.

• At the agency level, lack of a common enterprise architecture repository model and lack of department-wide integration contributed to producing little of real value. Program management by the Office of Management and Budget (OMB) and compliance activities were time-consuming and confused by complex and subjective assessment criteria. Gaver’s report notes that, “at least until very recently, federal agencies were required to submit two quarterly reports, the Enterprise Architecture Assessment Framework (EAAF) report and the Enterprise Architecture Segment Report (EASR), to OMB to report on the status of their respective Enterprise Architecture programs.” (To that, I’ll add that enterprise architects themselves were known to complain that rather than really leveraging enterprise architecture to improve the mission of an enterprise that touches some 300 million people — the good old U.S. of A. — their work seemed to have become relegated to a compliance-only activity.)

• At the federal level, the Federal Enterprise Architecture Management System (FEAMS) failed, and so failed to serve as the foundation of the entire Federal Enterprise Architecture. Worse yet, Gaver notes, “what also hasn‘t been understood is that FEAMS was actually just one of a series of related but disjointed efforts to collect and integrate EA data” and that all of these efforts focused only on subsets of data that were originally supposed to have been  included in the FEAMS system.

I could go on, as Gaver certainly does, pointing out problems. One of them, for instance, is that the regression of EA maturities “should have been a red flag indicating that there were significant underlying problems with the federal EA program.”

All Is Not Lost

We could use a little good news right now, and Gaver gives us some. He does believe that the federal enterprise architecture can be rehabilitated. What’s required is taking it out of its “swamp of sloppy definitions and misused words, grand definitions of architecture that too often have little or nothing to do with real architecture, and poorly differentiated functionality, all currently lumped indiscriminately under a common and misnamed banner.”

In spite of its own failures, he says, the Federal Enterprise Architecture program has led to some successes, with some agencies managing and modernizing their IT resources. In addition, a couple of dozen e-government initiatives are what Gaver calls by-products of a key notion of enterprise architecture. 

In fact, when it comes to open government, enterprise architecture is setting itself up to fulfill some high hopes. In the second report I referred to, “An Open Government Implementation Model: Moving to Increased Public Engagement” (2011), sponsored by the IBM Center for the Business of Government, authors Gwanhoo Lee of the Kogod School of Business at American University and Young Hoon Kwak at the School of Business at The George Washington University say that establishing enterprise architecture early on is key to successful open government initiatives. Efforts such as the open government portal of the Department of Health and Human Services and the Centers for Medicare and Medicaid Services’ dashboard are leading the way.

As more sophisticated portals come on line, management complexity also grows, and could inhibit their sustainability, the authors write. They advise: “Agencies need to develop high-level enterprise architecture in the early stages of their open-government implementation and standardize, simplify, and integrate data, tools, systems, and pro­cesses wherever possible.”

While EA makes up only a small part of the discussion in this paper, it clearly holds a prominent position in getting agencies from the point of increasing data transparency, to improving open participation and collaboration by citizens, to an era of ubiquitous engagement both through mobile tools and seamless integration of methods, tools and services within and across government agencies. 

My conclusion from reading the two reports is that the rehabilitation Gaver speaks of had better start soon if enterprise architecture is to be a strong foundation for broader government efforts. Do you agree?

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.