Enterprise Architecture Design

User-centric Enterprise Architecture provides information to decision-makers using design thinking, so as to make the information easy to understand and apply to planning and investment decisions.

Some examples of how we do this:

  1. Simplifying complex information by speaking the language of the business (and not all techie).
  2. Unifying disparate information to give a holistic view that breaks the traditional vertical (or functional) views and instead looks horizontally across the organization to foster enterprise solutions where we build once and reuse multiple times.
  3. Visualizing information to condense lots of information and tell a story—as the saying goes, a picture is worth a thousand words.
  4. Segmenting end-users and tailoring EA information products to the different user groups which we do with profiles geared to executive decision makers, models for mid-level managers, and inventories for the analysts.

Interestingly enough, in the summer issue of MIT Sloan Management Review, there is an article called “How to Become a Better Manager…By thinking Like a Designer.”

Here are some design pointers from the experts that you can use to aid your enterprise architectures (they are written to parallel the principles from User-centric EA, as I have previously described above):

  1. Embrace simplicity—“people often confuse simplicity…with simplistic….it takes courage to be simple…and the simplest solution is often the best.”
  2. Look for patterns in the data—“good problem solvers become proficient at identifying patterns.” Further, designers seek “harmony to bring together hierarchy, balance, contrast, and clear space in a meaningful way.”
  3. Apply visual thinking—often managers…rely heavily on data and information to tell the story and miss the opportunity to create context and meaning,” instead managers need to “think of themselves as designers, visual thinkers or storytellers.”
  4. Presenting clearly to specific end-users—“good design is about seeing and communicating clearly.” Moreover, it’s about “seeing things from the clients point of view…designers learn pretty quickly that is not about Me, it’s about You.”

MIT Sloan states “we have come to realize over the past few years that design-focused organizations do better financially than their less design-conscious competitors…design is crafting communications to answer audience needs in the most effective way.

This is a fundamental lesson: organizations that apply the User-centric Enterprise Architecture design approach will see superior results than legacy EA development efforts that built “artifacts” made up primarily of esoteric eye charts that users could not readily understand and apply.

Information Management Framework

The Information Management Framework (IMF) provides a holistic view of the categories and components of effective information architecture.

These categories include the following:

Information-sharing--Enable information sharing by ensuring that information is visible, accessible, understandable, and interoperable throughout the enterprise and with external partners.

Efficiency--Improve mission efficiency by ensuring that information is requirements-based, non-duplicative, timely, and trusted.

Quality--Promote information quality, making certain that information provided to users is valid, consistent, and comprehensive.

Compliance--Achieve compliance with legislation and policy providing for privacy, freedom of information, and records management.

Security-- Protect information assets and ensure their confidentiality, integrity, and availability.

All areas of the framework must be managed as part of effective information architecture.

Industry Architecture—What’s in a Name?

ComputerWorld, 22 June 2009 has an opinion piece, called “The Benefits of Working Together,” about developing an “Industry Architecture (IA)”—in this particular case for the hotel industry.

It takes the concept of a company or organizational architecture and applies it across an entire industry.

“In difficult economic times, every company seeks cost reductions and process improvements. But now an entire industry has banded together to help its constituents maximize their IT-based assets.”

I can see how from a private sector approach, IA is a way for companies to work together and benefit their overall industry through:

  • Improved IT products—“a clear architectural roadmap allows suppliers to focus efforts on the capabilities most important to customers.”
  • Lower IT product costs—standardized products from suppliers are generally less costly to produce than customized one (but they are also less differentiated and may be less exciting and inviting to customers). The IA also facilitates component reuse, standardized interfaces, and so forth.
  • Lower training costs—IA could reduce training costs, since there are standard processes and products spanning the entire industry meaning that employees can move more seamlessly between companies and not have to learn a whole new way of doing things.
  • Improved agility—industry standards allow for faster deployments and configurations of IT.
  • Increased buyer confidence—industry architectures could provide for a “product certification program”, so buyers can have confidence that IT products meet guidelines and are interoperable with other IA certified products.
  • Improved security—IA can incorporate IT security standards, resulting in companies being more secure than if they had “conflicting security approaches.”

From a public sector perspective, the Federal Enterprise Architecture (FEA) is similar to Industry Architecture in the private sector. Ideally, the FEA looks across all the federal departments (like an IA looks across the various companies in an industry) and creates a roadmap, standards, certification programs, interopability, component reuse, umbrella security, and more resulting in lower IT costs, more agility, and improved service to the citizen.

In terms of naming conventions, we can come up with all types of architectures from company architectures to industry architectures, from solution architectures (for meeting specific requirements) to segment architectures (for specific lines of business). We can develop horizontal architectures (across entities in the same stage of production or service provision) or vertical architectures (in entities that span different stages of production or service provision). We can create national architectures (like it looks like we may end up doing the financial services sector now) or perhaps even global architectures (such as through environmental, economic, or military agreements and treaties).

Whatever we call the various levels of architecture, they are all enterprise architectures (just with the “enterprise” representing different types or levels of entities). In other words, an enterprise can be a company or industry, an agency or a department in the federal government. Some enterprise architectures are bigger than others. Some are more complex. But what all these enterprise architectures have in common is that they seek to provide improved IT planning and governance resulting in cost savings, cost avoidance, and performance improvement for the enterprise in question.

So, we must at all levels continue to plan, develop and implement our enterprise architectures so that we realize the benefits – from the micro to the macro environment – of both private and public sector best practices. 

EA at Federal Emergency Management Agency


Check out this excellent enterprise architecture video of Mr. Ira Grossman from Federal Emergency Management Agency (FEMA). Mr. Grossman has many years of valuable experience in the EA field at NOAA, FDIC, and most recently FEMA. He truly exhibits an excellent understanding of the how EA fits into the big picture of the business and IT. One thing is that the model on relationships could be a "little" more user-centric. Watch, learn, and enjoy!