Organizational Hubris and Enterprise Architecture

Organizational arrogance is the anathema of user-centric EA.

In Fortune Magazine, 20 August, 2007, in the article “Don’t be Arrogant”, it states “when a company attains extreme market domination, hubris and a sense of infallibility can’t be far behind.”

When an organization (like an individual) is riding high on its fortunes, it forgets that it is not infallible and that we are all vulnerable — whether we know it or not.

Many individuals, organizations, and empires have seen themselves propelled from rags to riches, and then back again. Anyone planning on buying a GM car or seen a Roman legionnaire lately?

Judaism has a really neat view on this, called the “gilgal ha’chozer” which is the cycle of life. In this cycle, anyone can be elevated or lowered in life depending on their deeds (good and bad). Similarly, the Buddhist depict this concept in “the wheel of life”, where lives and fortunes rotate from happiness to despair and back.

User-centric Enterprise Architecture recognizes that organizational hubris is an organization’s eventual downfall. EA’s mandate is to look beyond today, see the potential hazards and changing conditions, and adjust accordingly. Every organization is vulnerable whether to changing market conditions, competitions, or new and unfolding mandates. User-centric EA provides a way for us to recognize changing conditions, plan accordingly, and plot a new course.

Organizational Hubris and Enterprise Architecture

Enterprise Architecture – Ask Lots of Questions!

In User-centric Enterprise Architecture, we ask lots and lots of questions.

Why do we ask lots of questions?

In User-centric EA, we are not satisfied with the status quo. User-centric EA demands that we analyze problem areas and look for better ways of doing things. One important step in analyzing the "as-is" state is to question it. That means, we capture the current state, but then we ask about gaps, redundancies, inefficiencies, and opportunities. The purpose of asking and drilling down on the information in the architecture is to get a deeper understand of the business processes, the information requirements, and the technology solutions that can be brought to bear.

Albert Einstein said, "Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning."

Yesterday is EA history, today is the "as-is" architecture, tomorrow is the "to-be" architecture, and questioning is what we must do to make it all happen.

Enterprise Architecture – Ask Lots of Questions!

Need to Know or Responsibility to Share

User-Centric EA is all about information sharing.

This vision of information sharing has the support at the United States Coast Guard, of Commandant Thad Allen. He has had a huge impact in the information sharing in the organization with his vision of "information transparency breeds self-correcting behavior". The doctrine of openness and sharing toward an outcome of improved personal and organizational performance is a powerful vision that can even transform a large, multi-mission maritime organization like the Coast Guard.

In public and private sectors, it used to be information on a "need to know" basis. Information is power and those who wield it are king. Only with the advent of the internet, social networking, vertical and horizontal integration in the marketplace, and the unfortunate 9-11 tragedy has need to know been shifting to "responsibility to share".

Undoubtedly, there is still a long way to go in eliminating the stovepipes in our organizations and between our organizations, but user-centric EA will be there to facilitate this change and build the mechanisms, processes, and governance for bona fide information discovery and exchange. More than that, by developing EA information products, governance processes, and plans, user-centric EA is creating a climate of change that will take organizations into the future of information-sharing.

Need to Know or Responsibility to Share

Steve Jobs and Enterprise Architecture

User-centric EA shares Steve Jobs (Apple's) vision for aesthetics, simplicity and minimalism, and innovation.

On July 25, 2007, the Wall Street Journal reported that "the new Apple cellphone famously does without the keypads that adorn its rivals. Instead, it offers a touch-sensing screen for making phone calls and tapping out emails. The resulting look is one of the sparest ever for Apple, a company known for minimalist gadgets. While many technology companies load their products up with buttons, Mr. Jobs treats them as blemishes that add complexity to electronics products and hinder their clean aesthetics…

With the iPhone, Mr. Jobs is making a similar gamble that users will quickly familiarize themselves with typing text and phone numbers on the device's "virtual" keyboard -- a set of "buttons" simulated by software rather than etched in plastic keys on the front of the device.

Like Steve Jobs' aesthetic and innovative approach to the design of consumer products, user-centric EA shares these principles in the development of information products to meet users' information needs. User-Centric EA is looking to provide useful and usable information products. To accomplish this, User-Centric EA designs information products so they are look good, are simple to understand, focus on transmitting meaningful information to decision makers, and are creative and interesting for users to use as a resource.

Steve Jobs' product design brilliance is a model and an inspiration for information design and knowledge management.

Steve Jobs and Enterprise Architecture

EA and the Law of Diminishing Returns

One of the best known economic laws is the law of diminishing returns, which states that past a certain point, the more input of something, the less additional output. While this law is typically applied to production, I believe this can also be applicable to the growth of service organizations (like those found in government or the private sectors) in that past a certain size, adding more people, funding, or whatever yields less additional benefit for the enterprise.

In the organization, size matters. In a larger organization, the diminishing returns takes the form of more complexity and less efficiency. While in a positive sense, a larger organization can do more, service more people, generate more goods, and overall accomplish more. However, as the enterprise grows, it benefits less and less, since the organization get "weighed down". Bigger often (but not necessarily) is not better, since it can mean more stovepipes, more redundancy, more levels of management and oversight, more bureaucracy, more complexity and so on. While on the other hand, lean can often mean more nimble, flexible, and agile. To me this is similar to the story of David and Goliath, where the giant Goliath is outmaneuvered and taken down by the smaller David.

The Law of Diminishing Returns with respect to large organizations has two major implications to EA:

• In a larger organization, the size and complexity can make executing a sound EA program more challenging. In some cases, there may actually be multiple EA programs or no viable EA programs, because "everyone is doing their own thing", and seemingly no one can make them stop.
• A large (unwieldy) organization can actually benefit from EA more than a smaller one, since EA is designed to help those areas that weigh the large organization down. For example, EA looks to eliminate stovepipes in the organization. EA works to reduce gaps and redundancies. EA looks to establish standards and build interoperability. EA shores up and provide support to the organization collapsing under it own weight.

So large, complex organizations can be a challenge to the EA practitioner, but they can also yield the biggest dividends.

EA and the Law of Diminishing Returns

A Bar Mitzvah Lesson and Enterprise Architecture

When I was bar mitzvah (this is the rite of passage when a Jewish Male reaches the age of 13 and accepts upon himself the laws of the Torah), my bar mitzvah teacher taught me an important religious and life lesson. This lesson impacts everything I do including the way I carry out my professional life leading Information Technology and Enterprise Architecture.

As part of the preparation for the bar mitzvah, a Jewish boy learns to read from Torah and prepare the section for the Shabbat reading that coincides with his 13^th birthday. I had a teacher from the local synagogue that prepared me well, for over the better part of a year. At the end of the training, my teacher told me "in life, just remember, stay far from evil and do good —this is the essence of the Torah's teaching"..

Now what does this have to do with IT and EA?

Well to me, the "final" bar mitzvah lesson was all about a life (and work) ethic. The lesson instilled in me a direction to look at the world and recognize good from bad and to always try to do good – do my best, improve things, have an impact!

While this lesson has many ramifications in my life, from a professional perspective, I enjoy the fields of IT and EA, where I can drive technology change for the improvement of the organizations I work for. While, I'm not out there "saving lives," I feel that I can make a difference by driving positive change using technology, structured with enterprise architecture, planning, and governance to make things better, more efficient, and improve mission execution.

It's been quite a while since my bar mitzvah, but the capstone lesson of "do good", helps me be a better Enterprise Architect and drive positive and substantial change.

What life lessons drive you to be successful in EA?

A Bar Mitzvah Lesson and Enterprise Architecture

Kaizen and Enterprise Architecture

User-Centric Enterprise Architecture and Kaizen are blood brothers — both are dedicated to improvement.

I love Kaizen! Kaizen is the Japanese philosophy of continuous improvement. Kaizen seeks “change for the better” and has been adopted by many companies in Japan as their equivalent of Six Sigma or Total Quality Management (TQM). Toyota is one of the best known and often cited examples of successfully implementing Kaizen; they have made kaizen part and parcel of their auto production process. Kaizen is an enterprise-wide endeavor. In a kaizen environment, the organization experiments to find better ways of doing things and then when these superior ways are found, they become the new standard throughout the organization.

In user-centric EA, there is also a focus on standards, integration, and process improvement. In EA, these are facilitated by the EA knowledge base of business and technical information, the analysis of problem areas and identification of gaps, redundancies, inefficiencies, and opportunities, and the institutionalization of regular and meaningful planning and good governance for maximizing the value of investments to the enterprise.

While kaizen is often associated with improvement to production systems including quality control, testing, and assurance, it is also a way of approaching work, education, relationships, and life — it’s when one is constantly asking “how can I do better” and actually following through (not like the typical New Year’s resolutions).

To me, EA is similar to kaizen in that it seeks to capture information, analyze it, and find ways to improve things. In EA, this search for continual improvement manifests itself by filling information gaps for users, eliminating organizational stovepipes, delivering IT solutions that meet requirements, consolidating redundant systems, and facilitating business process reengineering or improvement.

Do you view EA as a form of kaizen? How do you use EA to improve organizational processes and functions?

Kaizen and Enterprise Architecture

Hollywood Has the Vision, Why doesn’t the CIO or EA?

Star Trek, Star Wars, Battlestar Gallactica, James Bond, 24, and so many more films are creative and future looking. Indeed, Hollywood seems to be the global repository for creative talent and vision. In Hollywood, they are able to see things in the future or in fact, mold the future in ways that the rest of can’t.

But isn’t the role of the Chief Information Officer (CIO)and Chief Enterprise Architect (CEA) to not only to meet the mission needs of today, but also to plan for the technology needs of tomorrow? From the technology perspective, it is the CIO and CEA that especially need to be looking prospectively, with innovation and foresight, to understand the mission needs of tomorrow and what technologies can fulfill those needs.

Moreover, it is apparently, not only technology executives that seem to struggle with planning and vision, but there seem to be so many examples of organizations in the public and private sectors reacting to events, rather than “thinking out of the box” and proactively preparing for what could be (9-11, Hurricane Katrina, the auto industry, the stock market bubble a few years ago, are but a few in recent times).

Yes, it’s easy to talk with 20-20 hindsight, but are many of these events really so hard to envision and plan for. Are we so fat and happy that we can’t see beyond today?

User-centric EA believes that we must not only meet the needs of today, but that we must have vision and creativity and courage to see beyond today. This means that we need to envision not just what is, but what could be. It mandates that we increase our capabilities and competencies, so that we can really go with our minds and innovation “where no man has gone before”.

Hollywood Has the Vision, Why doesn’t the CIO or EA?

Enterprise Architecture: Program or Project?

Enterprise Architecture is a program with many phases and projects.

Several times in my career, I have been brought in to develop an enterprise architecture for an organization, and just about every time, the boss has asked how long will it take, when will it be done, or some other similar version to time-bind the effort.

However, for those of us who are practitioners in the field of EA, we know resolutely the answer is that EA is never done.

Legally, EA is mandated by the Information Technology Management Reform Act (a.k.a. the Clinger-Cohen Act). As such, it is not a one-time event, but an ongoing requirement, and thus an established program in every department of the federal government.

But more than that, EA defines the current, target, and transition plans for an organization. And by definition, a current and target are just snapshots in time, which are in essence outdated a moment after you publish (just like when you drive a new car off the dealer lot and it immediately becomes “used.”) That is, an organization, its business and technology, are constantly evolving and in a state of flux, responding to internal and external factors (such as new mission challenges, business opportunities, congressional or executive mandates, changing customer expectations, new technologies, and so on). So in an ever-evolving organization, the “current” state does not stay current, and the “target” does not stay current (up to date). That is, unless you place these under “maintenance,” i.e. you refresh these on a periodic basis, and make course corrections along the way.

Further, developing and maintaining an EA for any organization is a challenging task, especially for a large and complex organization (like many in the federal government). As such, EA efforts need to be broken down into smaller projects to be successful. And these projects need to be clearly defined in terms of scope, schedule, and performance measures and managed for all project knowledge areas (reference: Project Management Book of Knowledge).

So the next time your boss asks you, “When will the EA be done?” I suggest you tell them: “The EA is a program with many phases and projects. Phase (#) is scheduled to roll out (date).”

Has this ever happened to you – that your boss asked you when the EA would be finished? What did you say/do?

Enterprise Architecture: Program or Project?

Virtual Relationships and Enterprise Architecture

User-centric EA is based on establishing relationships. There are relationships with stakeholders, which includes understanding their information and governance needs and working to fulfill those. There are also relationships with subject matter experts in both the business and technical areas of the enterprise -- since EA bridges the worlds of mission-business and technology, the chief Enterprise Architect must build relationships in both worlds and facilitate information flow (discovery and exchange) between them and into architecture and planning products for the organization.

EA relationships are real, not virtual

Virtual world online games, such as Second Life, have simulated seemingly all facets of human existence, even relationships. The Wall Street Journal, on August 10, 2007 reports that studies show that "virtual relationships mirror real life...people respond to interactive technology on social and emotional levels much more than we ever thought...on a neurological level, players may not distinguish between virtual and real world relationships studies suggest."

However virtual relationships are not real relationships, which is required for User-centric EA. EA requires building genuine real world relationships, gathering requirements, developing user-centric solutions, and communicating on all levels with stakeholders and partners.

Also, EA is not a game (obviously!). It has real world implications for an organization if done correctly (or not). The results of EA can be the difference between executing on mission and pretending to be fat and happy in Second Life.

How important are relationships to your EA program?

Virtual Relationships and Enterprise Architecture

Bureaucracy and Its Impact on EA (and vice versa!)

Bureaucracy dulls even Enterprise Architecture, but EA fights back and unleashes innovation, spontaneity, and the human spirit.

Bureaucracy in organizations is an outgrowth of its being viewed, designed, and operated as a machine. The great sociologist, Max Weber, noted that modern organizations, that run like machines, tend to be very bureaucratic in nature, with strict hierarchies and structures. Frederick Taylor’s Time and Motion Studies advanced the mechanistic view of the organization and the production line mentality of the workplace, by promoting the division of labor and the highly monotonous, standardized work routines of laborers.

Treating organizations (and their people) as machines has a dehumanizing effect. While it is designed for unbending structure and for achieving predetermined performance goals, it creates endless barriers and obstacles to handling new challenges and adjusting to changes. In this type of super-strict organizational structure, even fields like EA (and its practitioners), which are designed to manage change, can be strangled by the embedded bureaucracy.

In bureaucratic enterprises, issues do not get addressed and resolved at the lowest levels where they are first encountered and can be handled most efficiently by those with subject matter expertise. Instead they get pushed up the chain of command, where ingrained organizational silos, competing interests, and empire building hamper an effective response. In frustration, management throws their hands up and assigns the issues to working groups or task forces or consultants who are assigned to try and deal with change. But these “outside groups” too, even if they can grasp the complexity of the issues, cannot effectively resolve them due to the barriers to organizational change that exist in the organization.

Despite the best intentions of all, bureaucracy is typical in large businesses and in government as well.

In user-centric EA, the impact of mechanistic organizations and bureaucracy is recognized as an impediment to change and growth of the enterprise, the ability of the organization to meet its full operating potential, and the valuation of its people as its greatest asset. EA is dedicated though to unleashing human capability and building a better organization for the future.

How does EA do this? By capturing and analyzing the as-is environment, and formulating a to-be environment and transition plan, EA not only shows the organization where its gaps, redundancies and inefficiencies are, but also facilitates a proactive solution to resolving them.

Further, EA provides two valuable assets to facilitate organizational change. The first is that EA provides business and technical information to all levels of the organization. This information can be used to enable decision-making by all. Secondly, EA provides a mechanism for governance, so that there is a structure and process for enterprise decisions to get made across traditional stovepipes.

By envisioning what could be, rather than just what is, EA challenges the status quo (even a highly mechanistic one) and continues to chip away at it, slowly but surely—working to eliminate stovepipes, build integration, interoperability, information sharing, and an open environment where people can innovate, create, and truly contribute to its success.

Bureaucracy and Its Impact on EA (and vice versa!)

What can ITIL teach us about EA

The Information Technology Infrastructure Library (ITIL) and User-Centric Enterprise Architecture are both customer driven and focused on providing users what they need to carry out the mission of the organization. Both are about achieving results.

ITIL and user-centric EA look like they compete, but really are mutually supportive. Here’s how:

• ITIL is a framework of best practices that seek to provide information technology service support and delivery to the end-user; User-centric EA focuses on the end-user and seeks to provide them useful and usable products and services.
• ITIL looks to match service levels to user requirements; user-centric EA looks to match technology solutions to business and information requirements.
• The ITIL framework has both a business perspective and an IT perspective — sounds familiar to EA? EA synthesizes business and technology information for enhancing decision making.
• ITIL looks at all the following: business, applications, infrastructure, security, service, and planning; EA’s views include business, performance, information, service components, technology, security, and develops the plans for these.
• ITIL is an outgrowth of the United Kingdom’s Office of Government Commerce; EA is rooted in the United States Clinger-Cohen Act and the Office of Management and Budget’s Federal Enterprise Architecture.
• ITIL provides goals and activities for all types of IT processes including: the management of configuration, incidents, problems, change, service levels, finance, availability, security, capacity, and continuity; EA provides an as-is, to-be, and transition plan for information systems and technologies in relation to performance, business, and information requirements. Both ITIL and EA are looking to enhance mission execution.

At the end of the day, both ITIL and user-centric EA provide a framework and structure for IT to better service the business and its end-users. ITIL will provide for the process side and EA will do the same for the planning and governance.

What can ITIL teach us about EA

The 4 Step CASA Model to User-Centric EA

There are four steps in user-centric EA, aligned to the process-outcome model (input, process, output, and outcome):

• First, we Capture information, implicit and explicit, structured and unstructured, in the organization, such as mission, vision, strategy, goals, business opportunities, current and emerging technologies, and so on (these are our INPUTS)
• Second, we Analyze the information in the EA program; we evaluate the information and catalogue it (this is the PROCESS phase)
• Third, we Serve up the information products to end- users in useful and usable ways to enhance decision making. One way we do this is through effective usage of information visualization (these are the OUTPUTS)
• Fourth, we Achieve improved IT planning and governance and enhanced decision making capability for the end-user (these are the OUTCOMES)

Mi CASA es su CASA.

How does your EA program work?

The 4 Step CASA Model to User-Centric EA

Enterprise Solutions: If not one, why not one?

When I worked at the United States Department of the Treasury in 2002, there was a real push by Secretary Paul O’Neil for enterprise solutions. In fact, he used to say, “if not one, why not one?”

At the time, Treasury was composed of 14 different and diverse bureaus and they did not have a history of collaborating well together. When management spoke about the relationship between the bureaus, they would call them a “loose confederation”. Well it was really quite loose, as enterprise solutions were more a rarity than a norm.

But Secretary O’Neil’s push for enterprise solutions was poignant, and I was heading up the enterprise-wide initiative to develop an architecture for a Treasury Integrated Document Management System (IDMS) for document management, records management, workflow, and so on.

This initiative turned out to be successful and I presented this at the Treasury Financial Systems Symposium as a model for enterprise solutions and collaboration that year.

Looking back, Secretary O’Neil’s questioning of “if not one, why not one?” has stayed with me and has become a cornerstone of what I believe user-centric EA is all about. That is, in developing target architecture and transition plans, enterprise solutions needs to be a cornerstone--simplifying, standardizing, and integrating our IT infrastructure and systems for the benefit of the organization and the end-users.

What obstacles do you encounter in developing enterprise solutions?

Enterprise Solutions: If not one, why not one?

Enterprise Architecture is not Solutions Architecture

For many years, there was confusion in the architecture community between EA and solutions architecture. For example, I remember one of the agencies that I worked at putting together a request for proposal for contractors to develop an EA for some new systems. But it wasn’t EA that they were actually looking for; they really wanted a solutions architecture to automate some particular processes (but at the time they didn’t know the correct terminology or really understand the distinction).

However, the distinction is important and the Federal EA made major strides in this area in December 2006, when they released the FEA Practice Guidance that laid out the differences (and hierarchy) between Enterprise, Segment, and Solution Architecture.

• (At the highest level,) Enterprise Architecture is scoped on the agency, at a low level of detail, with impact focused on strategic outcomes, and the audience is all agency stakeholders.

• Segment Architecture is scoped on individual lines of business (LOB), at a medium level of detail, with impact focused on business outcomes, and the audience is the line of business.

• (At the lowest level,) Solutions Architecture is scoped on specific functions and processes, at a high level of detail, with impact focused on operational outcomes, and the audience is users/developers.

Why is this important?

From a user-centric EA perspective, all stakeholders benefit from a clear delineation of responsibilities: An overarching plan and governance is provided from the Chief Enterprise Architect (the strategic layer); a roadmap for the lines of business is served up from the program managers (the logical layer); and project solutions are developed by the technical staff (the physical layer).

Al three layers of the architectures work synergistically together for the end-user, by the lower levels aligning to and complying with those above, so that specific solutions fit into the line of business roadmap for enhanced business outcomes, and the LOB roadmaps, in turn, are aligned with the overall EA target architecture and transition plan for the organization.

Do you distinguish between Enterprise, Segment, and Solutions architecture?

Enterprise Architecture is not Solutions Architecture

EA and Principles of Communication & Design

User-centric EA is about providing decision makers with not only the relevant information they need (i.e. current, accurate, and complete), but also serving it up in an easy to understand and readily accessible format.

To accomplish this, user-centric EA provides clear principles of communication and design. These include the following:

• Focus on enhancing decision making
• Develop useful and usable information products and governance services
• Simplify complex information
• Classify information into consumable chunks
• Unify information by consolidating it and creating a common look and feel
• Maximize use of information visualization (visuals, graphics, charts, and so on)
• Provide accessibility through multiple robust delivery mechanisms (so users have the information when and where they need it)
• Distinguish Enterprise from Segment and Solutions Architecture (to be discussed in a future blog)

By articulating and adhering to these EA principles of communication and design, you will greatly further your ability to deliver on the promise of user-centric EA.

Do you use similar principles of communication and design in building your EA?

EA and Principles of Communication & Design

Is Strategy or Operations King?

Strategy (read EA) and operations are two sides of the same coin — both ultimately seek to provide service and support to the end-user — and both are critical to making IT “work” as a functional whole.

In the Wall Street Journal, July 30, 2007, a number of prominent CIOs weigh in on the future of these two facets of IT.

Frank Modruson, the CIO of Accenture, predicts that within ten years, “you will see CIOs focus even more on strategy, whereas operations will be industrialized and outsourced…”

Similarly, Steve Squeri, the CIO of American Express, foresees that “the days of tech leaders as relationship managers and ‘order takers’ will go by the wayside… technical architecture will become a core function of IT departments.”

Both CIOs provide compelling visions of strategy and architecture playing an ever more central role in the enterprise for meeting business needs.

Do you agree with their visions? How important is EA in your organizations?

Is Strategy or Operations King?

Why Harry Potter Loves EA

Harry Potter loves User-Centric EA, which is all about making order out of chaos.

No, EA is not wizardry, but it can be “magic” to an organization in need of structure, process, and governance.

Before implementing user-centric EA, the enterprise often looks quite disconcerting and in a state of disarray. I’ve seen organizations before EA, where they don’t know what systems they have in place, what hardware/software they are using, what information requirements they are trying to fulfill, or even what functions and outcomes they are working toward achieving — and hence the fear and panic when the dreaded “data call” comes down.

In transforming to user-centric EA, there is a lot of hard work including discovery and analysis, building structure and process, and developing realistic plans. There is also organizational resistance — a long standing nemesis of EA. In time, as the user-centric EA journey progresses, sensible change begins to overcome fear and resistance. At that point, we begin to have structure and process take root, and we learn what we have in the enterprise, where things are located, how many we have, and how old they are. With this knowledge and with a functioning governance process, we are armed to better plan for refresh, recapitalization, and modernization — and help to build an ordered path ahead.

Similarly (oh come on, it’s not that big a stretch), Harry Potter starts out a miserable and lonely boy living an upside down life — he is even forced to live in a cupboard under the stairs in his relative’s home. He is downtrodden by all. That’s until he is transformed by his learning and adventures at Hogwarts School where he becomes a skilled wizard and a mensch, develops meaningful relationships, learns what’s what in his life, and finally overcomes the evil Lord Voldemort, his life-long nemesis. Harry’s is a journey that spans from an early life in turmoil, through numerous hardships and self-discovery, and finally, overcoming many obstacles, he can pursue a way ahead for a life of love and future growth.

Why Harry Potter Loves EA

Is SOA like Legos?

A “service” is a repeatable business task. In Service Oriented Architecture (SOA), applications are built by assembling shared, reusable, modular services into automated business processes.

In SOA, applications development shifts from technology-driven with a focus on functions and features to business-driven with a focus on business processes and services.

SOA aligns well with user-centric EA where business is the driver for technology, rather than technology for its own sake.

In the Wall Street Journal (July 30, 2007), Meg McCarthy, the CIO of Aetna, compares SOA with Legos: With Legos, we have distinct pieces that can be joined and formed into a functional object and then can be taken apart and put together again in a different way, for another use. Similarly, in SOA, we have loosely coupled services linked for use in discrete tasks, and which can then be linked in alternate ways and reused for other tasks.

In SOA independent, interoperable software can be searched, discovered, and exchanged/shared. Thus, integration is achieved by invoking service calls for necessary information and functionality.

One example where we can benefit from integration and sharing is in government in today’s post 9-11 world, where inter- and intra-agency information sharing is vital for law enforcement and defense readiness.

SOA leverages modularity and component reuse to achieve a more agile IT environment that can more efficiently automate business processes and integrate our silos of people, process, and technology.

Have you seen any examples of SOA in action?

Is SOA like Legos?

EA Modeling is Key to Business Process Improvement

Modeling & simulation has been hailed as a national critical technology and vital to national economic leadership (Source: Congressional Modeling and Simulation Caucus).

Models are representations of real world phenomenon and are static (while simulations are dynamic).

In EA, models are used to represent business processes, data and information entities, and IT systems. These models can be unified into representations that detail all the following:

• Business processes required for mission execution;
• Information requirements to supports these business processes; and
• IT systems that serve up the needed information.

In user-centric EA, models are done not just for the sake of representing these realities but are done to improve organizational performance and results by the end users. Models are central in analyzing problem areas and identifying gaps, redundancies, inefficiencies, and opportunities. The desired outcome is business process reengineering and improvement, ensuring vital information flows to end-users when and where they need it, and to support these with information technology solutions that helps us perform better, faster, and cheaper.

User-centric EA acknowledges that models are static. However, EA models need to result in dynamic corrective actions to an organization.

To really get the benefit of these modeling efforts, they must be conducted throughout the organization, in all lines of business. Unfortunately the reality is that this is a heavy lift and requires extensive commitment of resources and resolve.

Are models critical in your EA efforts? How do you use them?

EA Modeling is Key to Business Process Improvement

EA and the Singularity

One of the many definitions of EA is that it provides for a current, target, and transition plan for the organization.

However, for those of you familiar with Kurzweil’s Singularity, EA planning looks increasingly challenging.

According to Ray Kurzweil, the famous IT futurist, technology changes at an exponential growth rate. In The Law of Accelerating Returns (2001), Kurzweil states, “There’s even exponential growth in the rate of exponential growth.” Kurzweil predicts that within the 21^st century, technological change will have hit such a rapid pace that we will reach “the singularity”, where machine intelligence will in fact, surpass human intelligence and all sorts of unbelievable technological achievements will ensue.

While we haven’t reached the singularity yet, the rapid pace of technological change is a reality we are all familiar with. In this environment of rapid change (and as Kurzweil would argue, ever increasing rapid change), it will be increasingly difficult to keep up and effectively perform EA.

As EA practitioners, we need to think about what it means to “get our arms around” the target, if we cannot effectively anticipate what the target will even look like given the rapid pace of change.

Of course, from a user-centric EA perspective, we must continuously imagine and envision our future state — for the sake of our end users — so that we are the masters over our future (and not just slaves to it).

EA and the Singularity

Where does EA belong in the enterprise?

Typically, EA is a program situated under the Chief Information Officer (CIO) i.e. in the Information Technology department. However, to maximize its effect on the end-user, EA should be elevated to a strategic mission-business functional area of the organization, for example under the Chief of Staff or similar such prominent function.

EA should be elevated in the organization because generally, it will have more impact for the benefit of the end-users, which is what user-centric EA is all about. It will have more impact because:

• It will be easier to capture and analyze information in the organization, because EA has a broader mandate and vantage point from which to conduct its activities.
• It will have the ears of executive management and therefore be in a better position to implement its recommendations and plans.
• It will be better able to synthesize business and IT information, because it will be functionally independent and will not be seen as biased or simply an extension of the CIO.
• It will be able to focus on identifying the information requirements from the business side of the house and to drive technology solutions from the IT side.
• Business will drive technology (rather than investing in new technologies for their own sake i.e. because they are new and “cool”), and therefore IT investments will align with business outcomes and improved organizational performance.

What do you think ─ should EA be part of the “IT shop” or should it be somewhere else in the organization?

Where does EA belong in the enterprise?

IT Governance—Make it a Benefit for the User

Traditionally, IT governance is viewed by the end user as an impediment to getting their IT projects done. It is seen as another opportunity for the IT department to say no or to throw up obstacles. The perception is that governance is a cover for the IT department’s own inefficiencies or inability to get the job done, lack or resources or know-how; or is due to the subjective whims of the IT senior staff and CIO.

However, in user-centric EA, governance is a help (not hindrance) for users in developing and implementing successful IT projects. The way user-centric EA does this is it manages governance, bringing together the enterprise’s subject matter experts from both the business and IT sides of the house and applying their collective knowledge and best practices to facilitate IT project success.

In user-centric EA, it’s not about saying yes or no -- although of course that is inevitable in approving projects, prioritizing them, and allocating funding -– but rather it is about achieving best value from limited resources and ensuring those investments are successfully deployed.

In user-centric EA, IT governance is implemented to meet the needs of the user community and IT stakeholders -– to help make IT projects a success!

Do you use user-centric IT governance? Or is this just a pipe dream?

IT Governance—Make it a Benefit for the User

Why was Human Capital left out of the Federal EA?

What’s missing in the Federal Enterprise Architecture (FEA) is the Human Capital Reference Model. The Human Capital perspective is critical in a user-centric EA.

In the FEA, there are five basic reference models that translate into EA perspectives (or views of information):

• Performance: Measurement of strategic and business outcomes
• Business: Functions and activities that drive performance
• Information: Information needed to perform the mission-business of the enterprise
• Services: Applications and service components that fulfill information requirements
• Technology: Underlying hardware and software that supports service delivery

Additionally, while FEA looks at security as a cross-cutting architecture perspective, I like to call it out as its own EA perspective (for emphasis), particularly in a defense or law enforcement environment.

Finally, to the point, human capital are the people and organizational entities that conduct both the mission-business and technology functions of the enterprise. John Zachman, the founder of modern-day EA included people (or the who) as one of the perspectives in the Zachman Framework. This makes intuitive sense to me.

In order to focus on meeting the requirements of the EA end users, we need to provide for a view of people in the architecture itself. For example end-users need to know who are the key players in the enterprise. Users also need to understand how they align to mission execution and how they will be measured for results. The enterprise and the users need this to build a sustainable high performing organization.

Why was Human Capital left out of the FEA?

Would like to hear any thoughts or opinions on adding a human capital perspective to FEA.

Why was Human Capital left out of the Federal EA?

How EA Benefits the Organization

Even though user-centric EA benefits the user, the big winner is the enterprise. EA helps us functionally, as follows:

• To plan better for IT refresh, recapitalization, and modernization
• To make better investment decisions
• To analyze problem areas and uncover gaps, redundancies, inefficiencies, and opportunities
• To drive business process reengineering and improvement
• To ensure information needs are met
• To deliver technology solutions that meet requirements
• To communicate, inculcate, and provide clear documentation about our enterprise

Technology-astute organizations know that user-centric EA is an elixir for much that ails their IT function.

Interested to hear from anyone on other organizational benefits…

How EA Benefits the Organization

How EA Benefits the End-User

In user centric EA, business drives technology rather than technology being implemented for technology’s sake.

In an EA where business drives technology, the end users benefit in the following ways, they:

• Understand better how technology aligns to the mission
• Are able to access information transparently, where and when they need it
• Operate freely, without stovepipes getting in their way
• Leverage applications that are interoperable, not standalone
• Use simple, standardized technologies
• Spend money more efficiently on the technologies they use
• Are confident that the information they have is accurate and secure
• See mission results from their business and technology investments

How EA Benefits the End-User

EA Owns Structure, Not Content

In user-centric EA, the EA program owns the structure of the information, not the contents. On the other hand, the business programs and technical subject matter experts own the contents of the EA, and are responsible for ensuring that it remains current, accurate, and complete.

In my agency, we have institutionalized these EA roles and responsibilities as follows:

• EA Product Stewards are the EA team members that develop and maintain the structure of the information products. The stewards are responsible for understanding user requirements, designing information products to fulfill these, facilitating the capture of information, analyzing and cataloging it, serving it up to the user through robust delivery mechanisms (such as EA website, handbooks, CDs, and so on), and keeping the information under strict configuration management. In these ways, the stewards ensure the products are relevant, understandable and accessible to the end-users.

• EA Product Coordinators serve as the content managers and approval authority for new and changed information in the architecture. The coordinators are responsible for participating in the development of the agency’s EA and ensure ongoing updates as new information becomes available. In this way, the coordinators ensure that the information in the EA stays relevant to the end-users.

By having these complementary roles of product coordinators and stewards, for developing and maintaining the EA, the users are assured useful and usable information for their needs.

EA Owns Structure, Not Content

In A Nutshell, Know Your Users

At the end of the day, user-centric EA is about focusing on the user!

We have know who they are, communicate with them, understand their needs, and work to fulfill them.

As this cartoon shows if we don’t read our users needs correctly, then the result is “starship enterprise” architecture rather than genuine user-centric EA.

(Source for Cartoon)

In A Nutshell, Know Your Users

Make It Accessible - Rule of Thumb #5

Finally, Rule #5 is make it accessible.

EA information is a wonderful tool, but to be valuable to the end-user it must be accessible to them when and where they need it. Therefore, you need a robust delivery mechanism for the information.

At our agency, we provide EA and governance information in multiple delivery channels. For example, the EA information is provided through a knowledge portal on our website as well as through printed handbooks and so on.

Our EA website homepage has our knowledge center that is the navigation mechanism to get to all product information in the repository. The information is available to users 24/7.

Make It Accessible - Rule of Thumb #5

Separate Forest From Trees - Rule of Thumb #4

Rule #4 is separate the forest from the trees.

What this means is that we provide the users EA information in various levels of detail that is tailored to their particular needs in the organization. Moreover, each level of information is drillable (or clickable) to the next, so that user can navigate between information views.

For example, in our agency, we use a three level metamodel representing high, medium, and low, or what we call, profiles, models, and inventories.

• Profiles are high-level, big-picture strategic views of the information; it’s the satellite view from 30,000 miles up, providing information to the executive in a quick, condensed format, usually a graphic.

• Inventories (or catalogues) are the detailed views of information usually in database or spreadsheet format, that is typically used by the analyst. It’s the trees versus the forest; the distinct configuration items with lots of information about each one.

• Models are the connection between the forests; they illuminate relationships between information that is especially useful to the mid-level manager working with his/her peers. These relationships include those that show how processes work, how information is exchanged between entities, or how systems interoperate.

In user-centric EA, it's not one size fits all!

Separate Forest From Trees - Rule of Thumb #4

Show, Don't Tell - Rule of Thumb #3

Rule #3 is show, don’t tell.

•This means that a picture is worth a thousand words. It’s all about using information visualization effectively.

•For example, in my agency's network profile, we show a graphic of the United States. We show the nodes on the map, each representing a major communication hub. We show alignment of these nodes to the agency's districts. And finally, we show the connectivity between the nodes, including the type of communication lines.

•This network profile can be used, for example, to envision connectivity being disrupted, whether through man-made or natural disaster, and how this would affect mission execution. This is a tool for helping us plan for continuity of operations.

Show, Don't Tell - Rule of Thumb #3

K.I.S.S. - Rule of Thumb #2

Rule #2 of user-centric EA is Keep It Simple, Smart (Person).

Executives and decision-makers are busy people and do not often have the time or patience to decipher what you are trying to say. That is why we need to keep things straightforward and focused!

For example, in my agency, we have our Business Profile, which identifies our major functions. It is categorized into three, simple, color-coded functional areas (core mission, mission support, and business support).

• •Under Core Mission, we have the mission programs of the agency (such as Search and Rescue, and Defense Readiness).
• •Under Mission Support, we have the functions that directly enable the performance of core mission, such as logistics management, command control and communications, and training.
• •Under Business Support, we have the back-office functions, such as finance, HR, legal, public affairs, etc.

We use this simple graphic as a starting point for understanding what we do, who we are, and what our organizational identity is.

I have presented this to senior executives in the agency and have received kudos for taking the functions of a large, multi-mission maritime organization and making it simple for anyone to understand.

K.I.S.S. - Rule of Thumb #2

How To Do It Right - Rule of Thumb #1

From my experience, there are a number of ways to transform your EA into a user-centric model. In this post I will talk about the first one: Have a clear value proposition.

Remember, doing EA because "it's the law" (Clinger-Cohen Act) is not focusing on the users!

One example of a clear value proposition is that "EA will improve our IT planning and governance" (and thereby enable better decision making by the end users).

It was not until I started speaking in these terms that anyone in my agency would give me the time of day.

How To Do It Right - Rule of Thumb #1

What is User-Centric EA?

Well, this is exciting...my first blog, dedicated to a subject that I am passionate about - user-centric enterprise architecture.

Let's start with some basic terms:

• Enterprise architecture (EA) is the discipline that synthesizes key business and technical information across the organization to support better decision-making. EA includes the development, maintenance and use of an as-is, to-be, and transition plan. Together, these serve as the blueprints for modernizing and transforming an organization to meet future mission capabilities and requirements. The goal of EA is to improve information technology planning and governance.
  

• User-centric EA focuses on providing useful and usable products and services to the end user. In user-centric EA, information is relevant, easy to understand and accessible. In contrast, traditional EA is user-blind because the focus is on developing "artifacts" that are often unintelligible. Therefore, in traditional EA, users often have difficulty understanding the as-is, to-be, and transition plan.
  

What is User-Centric EA?