SOA Best Practices

I came across these Service-Oriented Architecture (SOA) best practices and thought they aligned well with User-centric EA and were worth sharing:

(adapted from Naval Post Graduate School, Monterey, CA, Masters Thesis—SOA for Coast Guard Command and Control by Dash and Creigh, March 2007 — approved for public release):

• Know when to use services – Explicitly define the extent to which we will and will not use services; services are selected with intent and do not randomly spring up.
• Think big, start small – This allows us to validate the architecture, while giving the organization value, realized as usable services.
• Build on what you have – Reuse legacy application functionality and data wherever possible.
• Use SOA to streamline business processes – SOA is an inherently flexible and interoperable model for hosting application functionality; this provides an opportunity to rethink and improve business processes.
• Incorporate standards – Use industry web service standards for navigation, application logic, integration, data stores, and enterprise infrastructure.
• Build around a security model – Functional design needs to be built around security, and not vice versa (security cannot be added as an afterthought).
• Design with quality in mind – Quality must be designed into the product, and not inspected into it.
• Organize development resources – Group development team around logical business tasks, and not around technologies.
• Train developers – Ensure designers and developers have the skills to implement SOA properly.

Basic definitions:

SOA is a software design methodology that uses loosely coupled services to perform business functions and processes.

A service is an implementation of a well-defined piece of business functionality, with a published interface that is discoverable and can be used by service consumers when building different applications and business processes.

In general, I think SOA is a great fit with User-centric EA, because the focus is on providing functional business services to the end-user, as opposed to developing monolithic, stove-piped, and redundant applications. The end-user should not have to use countless non-integrated applications systems (or even computers) to get their information, but rather the information should be technically transparent and readily accessible based on their business requirements.

SOA Best Practices

IT Governance and Enterprise Architecture

User-centric EA provides Information Technology (IT) governance services by providing technical reviews for new or substantial changes to IT projects, products, and standards in the enterprise. The IT governance process assures there is alignment to and compliance with the EA.

The EA Board (EAB) consists of business and technical members. The EAB conducts technical reviews and answer the following types of questions in support of IT governance:

• How does the proposed system align with mission, vision, strategy, and goals (for example, how does the proposed change fit within the strategic, tactical, and operational plans of the organization)?
• How will information be shared across the enterprise and with its partners (for example through use of metadata and repositories)?
• How will the system be interoperable (for example, through open standards and modular components); also, are there any existing systems in the organization that can meet the needs of the user?
• How will technology standardization and simplification be met (for example, through use of approved enterprise products and standards)?
• How will performance be measured (for example, what indicators will be used and what represents success)?
• How will information be secured (for example, does the system have authority to connect and authority to operate)?
• How is compliance being met for such things as the Privacy Act, Federal Records Management Act, Section 508 of the Rehabilitation Act, and Federal Information Systems Management Act, and so on?

The EAB provides its finding and recommendations to the IT Investment Review Board (IRB), which has decision authority for all phases of capital planning and investment control (CPIC)—select, control, and evaluate. The IRB is responsible for evaluating, authorizing, prioritizing, and authorizing funding for IT investments and then for the ongoing oversight of cost, schedule, and performance of the investment. The IRB manages its investments as a portfolio (i.e. portfolio management) and ensures that the mix of investments meets business objectives and optimizes value (value, risk, and cost) for the enterprise. The IRB cannot do its job without input from EAB (in a sense, the EAB is the technical, working arm of the IRB).

EA has a critical role in IT governance. EA ensures that IT projects, products, and standards align to and comply with the architecture requirements and planning goals of the organization.

IT Governance and Enterprise Architecture

CONOPS, Proof of Concepts, Prototypes, Pilots, and Enterprise Architecture

User-centric EA seeks to implement successful IT governance for the enterprise. As such, it seeks to ensure that new systems not only meet users’ requirements, but also that organizational investments in new IT are successful.

There are a number of ways to phase in a new system to help ensure its success for the organization.

By first developing a clear definition of capabilities (CONOPS), and moving from proof of concept to prototype and to pilot, risk is mitigated on new system implementations and more systems are successfully brought to fruition. This phased systems development approach helps User-centric EA meets it target architecture and transition plan for the organization.

• Concept of Operations (CONOPS)—evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or a particular end state for a specific scenario.”
• Proof of Concept—a partial solution to a problem intended to prove the viability of the concept. A proof of concept may involve a small number of users acting in a business (non-IT) role using the system to establish that it satisfies some aspect of the requirements for the complete solution. The proof of concept is usually considered a milestone on the way of a fully functioning prototype.
• Prototype—an original instance of some thing serving as a typical example for other things of the same category. A prototype is built to test the function and feel of the new design before starting production of a product.
• Pilot—an initial roll out of a system into production targeting a limited scope of the intended final solution. The scope may be limited by the number of users which can access the system or by the business categories affected or the business partners involved or other restrictions as appropriate to the domain. The intent of a pilot project is to validate that the system is working in production as designed and limiting the business exposure if it is not.”

Note: Definitions of proof of concept, prototype, and pilot project were adapted from Wikipedia. The Definition for CONOPS was adapted from Navy Warfare Development Command (public website).

CONOPS, Proof of Concepts, Prototypes, Pilots, and Enterprise Architecture

SDLC, CPIC, PMBOK, and EA

User-centric EA seeks to align the various life cycle IT system processes to help users understand, navigate, and complete these as simply and smoothly as possible.

Below is an alignment of the processes for System Development Life Cycle (SDLC), Capital Planning and Investment Control (CPIC), Enterprise Architecture (EA), and the Project Management Book of Knowledge (PMBOK).

SDLC	CPIC	EA	PMBOK
Conceptual Planning	Select	Business Alignment	Initiating
Planning & Requirements	Control	Technical Alignment	Planning
Design			Executing
Development & Testing
Implementation
Operations & Maintenance	Evaluate	Architecture Assessment
Disposition			Closing

The graphic demonstrates that the various IT system processes align quite nicely, and that user seeking to stand up a new system or make major changes to existing systems can follow the basic 7 steps of the SDLC and complete the requirements of CPIC, EA, and PMBOK along the way (the touch points are all identified).

The way to read this graphic is as follows:

For example, in the first phase of the SDLC, the conceptual planning stage, the user does the following: 1) defines their need (SDLC process) 2) develop their business justification and seek to obtain approval and funding from the IT Investment Review Board (CPIC process) 3) develops their business alignment and seeks approval from the Enterprise Architecture Board (EA process), and 4) define their project and seek authorization to proceed (PMBOK process).

For CPIC, users identify the following:

• Select—How does the investment meet business decision criteria?
• Control—Is the investment being managed with the planned cost, schedule, and performance criteria?
• Evaluate—Did the investment meet the promised performance goals?

For EA, users demonstrate the following:

• Business Alignment—Does the investment support the agency mission?
• Technical Alignment—Does the investment interoperate within the technology infrastructure and meet technical standards?
• Architecture Assessment—Is there a need to update the architecture?

For PMBOK, users complete various project management processes:

• Initiating—Define and authorize the project.
• Planning—Define objectives and plan course of action.
• Executing—Integrates resources to carry out project management plan.
• Closing—Accept product or service.

Note: The EA/CPIC alignment is adapted from Architecture Alignment and Assessment Guide, Chief Information Officers Council, August 2001. The PMBOK definitions are adopted from the Project Management Book of Knowledge, Third Edition.

User-centric EA promotes the alignment of the various IT system processes to help users to easily understand the touch points in the various life cycle steps to getting their system up and running. Moreover, the alignment enables the CIO to develop processes and job aids to assist and ‘speed’ users through the process. Thus, the processes are transformed from inhibitors to facilitators of systems progress for the enterprise.

SDLC, CPIC, PMBOK, and EA

Psychopaths and Enterprise Architecture

In user-centric EA we are very focused on meeting the needs and requirements of the user community. However we need to beware of the fact that some users are "psychopaths" and do not have the best interests of the organization at heart.

In the book Snakes in Suits - When Psychopaths Go To Work by Babiak & Hare the authors identify these ill-intentioned people in the organization and why the organization tolerates them or is fooled by them.

"Psychopaths manipulate the system - they are selfish care only about themselves with little regard for fairness or equity. They allow the responsibility of leadership and the perks of power to override their moral sense. Some have embraced the mantra that greed is good and that success at any cost to others is justifiable and even desirable. And at the extreme some of these people have a true personality disorder rooted in lying, manipulation, deceit, egocentricity, callousness, and other potentially destructive traits."

As enterprise architects, we need to be continually on the lookout for what's best for the enterprise and not get sidetracked by those with ulterior motives or personal agendas.

Have you ever experienced a situation like this?

Psychopaths and Enterprise Architecture

Data Architecture Done Right

Data architecture done right provides for the discovery and exchange of data assets between producers and consumers of data.

Data discovery is enabled by data that is understandable, trusted, and visible.

Data exchange is facilitated by data that is accessible and interoperable.

Together, data discovery and exchange are the necessary ingredients for information sharing.

Why is it so hard?

Primarily it’s a coordination issue. We need to coordinate not only internally in our own organization (often already large and complex), but also externally, between organizations — horizontally and vertically. It’s quite a challenge to get everyone describing data (metadata) and cataloging data in the same way. Each of us, each office, each division, and so forth has its own standards and way of communicating. What is the saying, “you say poTAYtos, and I say poTAHtos”.

Can we ever get everyone talking the same language? And even if we could, do we really want to limit the diversity and creativity by which we express ourselves? One way to state a social security number is helpful for interoperability, but is there really only one "right" way to say it? How do we create data interoperability without creating only one right way and many wrong ways to express ourselves?

Perhaps, the future will bring artificial intelligence closer to being able to interpret many different ways of communicating and making them interoperable. Sort of like the universal translator on Star Trek.

Data Architecture Done Right

Five Pitfalls of Enterprise Architecture Review Boards

EA Review Boards are necessary for supporting sound technology investment management decisions (a.k.a. CPIC or capital planning and investment control).

However, the EA Review Boards often fail for the following reasons:

• The board has no power to enforce its decisions — this typically happens when the CIO does not control the IT funding in the organization.


• The board has no visibility to the IT projects being initiated across the enterprise — again, this is common when the CIO does not control IT spending and programs can fund their own IT pet projects.


• The board meetings are not well organized —this can happen when meetings are sporadic instead of regular, when meetings run over their scheduled times, when agendas are not followed, minutes not kept, and members are not given ample opportunity to participate and “be heard” in the meetings.


• The board members do not understand the “what’s in it for me” — the members on the review board feel that they already have “day jobs” and that participating on the EA review board is not their responsibility or is not relevant to what they do day-to-day.


• Board members lose interest over time — a pretty common symptom of this is when the members start “delegating” attendance and participation to less senior members of the organization (and those people may not have the same level of subject matter expertise or decision authority as the “official” members).

In User-centric EA, the focus of the EA reviews is on the stakeholders presenting their projects, on the members contributing to the reviews, and on both of these seeing that their participation results in better IT investment decisions and more successful projects for the enterprise.

Finally, the CIO through the Investment and EA Review Boards wields control over the allocations of funds and prioritization of technology investments.

Five Pitfalls of Enterprise Architecture Review Boards

Space Elevator and Enterprise Architecture

In User-centric EA, having a vision for the future is critical in developing the target architecture and transition plan.

At one time, man looked up at the heavens, and imagined that one day people would actually walk on the moon — and on July 21, 1969, this once unbelievable vision became a reality.

Today, some very smart people from Las Alamos National Lab, NASA Institute for Advanced Concepts, and MIT are envisioning a space elevator 62,000 miles long that would move along at 120 miles an hour. The top of the elevator would rotate with the earth at 20,000 miles an hour and could be used to springboard to the moon, mars, and beyond. Sounds crazy? Well, NASA has invested millions of dollars and 22 teams (mostly universities) have signed up for a competition to design the space elevator.

The point is that using the imagination to envision the future is a really important part toward actually making the leap forward. The ideas have to start somewhere, and while the ideas need to be moderated and prioritized, big idea thinking is imperative to both evolutionary and revolutionary change. Enterprise architecture is a great place for using creativity, imagination, and vision and opening up often insular organizations to new ideas and ever greater possibilities for the future.

Space Elevator and Enterprise Architecture

Darwin and Enterprise Architecture

User-centric EA seeks the long term preservation, maturation, and growth of the organization and its ability to deliver mission execution.

Charles Darwin stated that "in the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment.”

In the book Images of Organization by Gareth Morgan, Darwin’s theory of survival is extended from the individual to the enterprise. “Organizations, like organisms in nature, depend for survival on their ability to acquire an adequate supply of resources necessary to sustain existence. In this effort they have to face competition from other organizations, and since there is usually a scarcity of resources, only the fittest survive.”

Even in cases where resources are abundant and self renewing, organizations are always competing to survive. This competition takes the form of who can supply the end user with the products or services they need better, faster, and cheaper. The competition, in this case, is not for resources, but to be the resource to others. For in being the supplier of choice to its customers or stakeholders, the enterprise thrives and survives in executing its mission.

Indeed, in a competitive economy, there is always the opportunity for a competitor to arise and challenge the organization’s role in the marketplace. It is this competition that is considered not only healthy, but also a cornerstone for continuously improving product and service quality and keeping prices at bay for customers.

Even in government, where some may think there is no competition, agencies not only compete for limited resources (funds, people, and so on), but also for being the provider of choice to the citizens. As one example, in the federal government, there are several agencies that can provide banking regulation, such as the Office of the Comptroller of the Currency (OCC), the Office of Thrift supervision (OTS), the Federal Deposit Insurance Corporation (FDIC), and the Federal Reserve.

In a competitive environment, EA is a tool for business and technology planning and governance that helps an organization deliver on its mission and be the provider of choice to its customers.

Darwin and Enterprise Architecture

Why Isn’t There a Chief Data Architect in the Federal Government?

In the federal government, there is a Chief Enterprise Architect in the Office of Management and Budget (OMB) — this is a good thing.

But the question that I have is why there isn’t a Chief Data Architect as well?

We all know that one of the essentials to good architecture is having strong data architecture that provides for data descriptions (or metadata) to uniformly describe data, data context (or taxonomies) for discovery, and that supports data sharing (or exchange).

In the Federal Enterprise Architecture (FEA), there is a Data Reference Model (DRM). Moreover, in the FEA, data is the crucial touch point between on one hand, the business functions toward achieving desired performance outcomes, and on other hand, the services and technologies that serve up the data in order to perform the functions and activities of the enterprise.

Furthermore, in developing technology solutions of the enterprise, one very important question for the business is what their information and data requirements are. The answer to this helps drive the technology solution.

For the federal government, the benefits of maturing its data architecture could be significant, especially in being able to share vital information, and thereby fill gaps and reduce redundancy across the federal enterprise. Given the size and important scope of the federal government missions, the imperative is great!

The Chief Data Architect would focus on data issues and drive such things as data standardization, common lexicon, metadata development, exchange standards and directories, service oriented architecture, and overall information sharing.

What do you think--would a Federal Chief Data Architect be a good idea to help progress this?

Why Isn’t There a Chief Data Architect in the Federal Government?

Maslow’s Hierarchy of Needs and Enterprise Architecture

User-centric EA helps an organization meet its needs on many levels.

The great psychologist Abraham Maslow, in the Hierarchy of Human Needs, theorized that people seek to fulfill successively higher level of needs: first is basic needs like physiological and safety needs (sustainment needs), then loving and belonging (social needs), and finally self actualization (innate growth and upward movement).

I believe that Maslow’s Hierarchy of Human Needs can be extended to organizations as well.

User-Centric EA helps an organization fulfills the basic need to sustain itself and carry out its day-to-day mission (tactical), but also its higher order needs of socialization — to be connected, accepted, and held in esteem by its peers, partners, “masters” (those with oversight and budget authority), and stakeholders — and finally, its need to self actualize, where it finally achieves its core mission (strategic) and purpose for being and strives to be the best it can be, growing and broaden its reach and impact in the world.

How does EA do this?

• EA looks at the business and information needs of the organization to fulfill its mission and achieve results from operations (sustainment).
• EA seeks to develop common platforms and enterprise solutions — i.e. horizontal and vertical integration and cost-efficiency — as well as information sharing with its peers i.e. to work collaboratively with others in partnership and achieve its mission more effectively and efficiently (social).
• EA is forward looking and strategic, and seeks to drive business process reengineering and improvement and make use of emerging technologies and other best practice advances to help the enterprise be better in the future than it is today (self-actualization).

Maslow’s Hierarchy of Needs and Enterprise Architecture

Leadership Styles and Enterprise Architecture

Is being a good leader about being a dictator or facilitating decision by consensus?

The Wall Street Journal, 11 August, 2007 reports that Mr. Gou the founder and chief of Hon Hai Precision Industry Company, the largest exporter in China (a company with annual revenue of $40 billion and 450,000 workers) believes that "the important thing in any organization is leadership…a leader must have the decisive courage to be a dictator for the common good".

In America, we do not like the idea of dictators, nor do we believe that we get good decisions from that style of leadership. However, certainly, we've all seen organizations where competing interests, personality conflicts, scarce resources, and silo mentalities contribute to stagnation and floundering performance. In these environments, a strong leader can sometimes be a welcome antidote — Not that anyone wants to be dictated to, but a leader that can provide a clear vision, direction, and unclog the routine bottlenecks can sometimes set an organization back on path of forward momentum.

User-centric EA is a proponent for "bringing people along", for decision by consensus, and for valuing individual and cultural diversity. We get a better decision and a better product by hearing opposing points of view and working things out. At the same time, organizational leadership is a necessity and sometimes a leader has got to hear the opposing points of view and then "get off the dime" and make a decision.

Leadership Styles and Enterprise Architecture

Austerity and Enterprise Architecture

User-centric EA believes in planning for the future —often uncertain, but always full of potential.

Fortune Magazine, 20 August, 2007, identifies an important tenet of Carlos Slim (the richest man in the world) as follows: “maintain austerity in prosperous times (in times when the cow is fat with milk); it accelerates corporate development and avoids the need for drastic changes in time of crisis.”

While user-centric EA cares about the individual, it also must take into account the needs of the overall organization and “the greater good.”

User-centric EA is not about being miserly, but rather about being frugal. It’s not about being pessimistic about the future, but about having a plan to weather whatever may come. In user-centric EA, planning includes alternative analysis and looking at the spectrum of all options. User-centric EA is about diversifying capabilities and at the same time building competencies and differentiating.

User-centric EA adopts planning as the mechanism to “maintain austerity”, to “accelerate corporate development”, and to “avoid the need for drastic change in time of crisis”. EA is a stabilizing factor for an organization in an ever changing world.

Austerity and Enterprise Architecture

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