A good communication strategy is an essential element of a successful enterprise architecture program. The purpose of a communication strategy is to make sure the right message (what) is delivered to the right people (who) at the right time and place (when and where) in the right way (how), in a way that ties back to the objectives of the program (why). This enables the organization to rally around a common vision for the future and agree upon a journey to get there.

Enterprise architecture (EA) attempts to optimize and align all aspects of an organization in the execution of its business. For this reason, all aspects of the business should be vested stakeholders in EA. An effective EA program must ensure that it communicates with these stakeholders. Furthermore, an EA program must also facilitate communications among the stakeholders themselves. It must generate dialogue between these diverse groups and drive for a common understanding of the vision and direction of the organization, acting as a mediator and facilitator.

Another important reason for a solid communication strategy is to clearly define the value of EA to the organization, and to ensure that the value is realized by implementing the required changes. It is easy to see how EA can be viewed as an “ivory tower” discipline if it fails to make these changes and deliver real value. EA must not only recommend changes, but must also enable change. To accomplish this, a high level of coordinated communication is required. This can only be achieved through a planned and deliberate approach. Enter the communications portfolio.

To better understand the role of a communications portfolio, I met with our own communications specialist, Lynn Gorny. Lynn has played key roles in implementing effective communication strategies within numerous organizations, including the Canada Revenue Agency. According to Lynn:

“An effective communications portfolio consists of strategic, operational, and tactical communications. Strategic communications support the long term goals and strategic objectives of the organization. They are program-oriented and drive awareness and buy-in on the future vision of the organization. Operational communications are targeted to a program or initiative and generate awareness or request a call-to-action to achieve specific results. Tactical communications are the day-to-day communications required to enforce policies, procedures, and exchange information among on-the-ground service delivery agents. The communications portfolio should contain strategies to address and connect each of these three types of communication.”

An enterprise architecture program must contain all of these elements to align and connect communications initiatives. It must contain strategic communications to make sure the value of enterprise architecture is understood across the organization and ensure that all participants are actively engaged. It must contain operational communications to generate awareness of specific change initiatives, policies and procedures. It must also contain tactical communications to address the implementation of these policies and procedures at a working level. An EA program which includes these three types of communication will be able to deliver the right message to the right people at the right time, helping to align stakeholders and achieve its objectives.

“That which does not kill us makes us stronger.”  I wouldn’t normally start a blog with a quote from Nietzsche, but in this case it seems appropriate.  I’m sure we have all heard these words of wisdom as children after a fall from a bike or a bad bout of the flu.  But these are not just words of comfort and encouragement: these words speak to the nature of evolution itself.

So what do Nietzsche and Evolution have to do with Enterprise Architecture?  Glad you asked.  Follow me through this thought experiment and find out. 

Evolution is Nature’s way of responding to environment circumstances.  Species evolve based on the propagation of characteristics that are beneficial to survival in their current environment.  Different pressures give rise to the development of different characteristics.  The environment puts stress on Nature, and Nature pushes back.  An example of this is the recent increase in antibiotic resistant bacteria. The prominent theory is that these are a result of the widespread use of antibiotics.  As bacteria are exposed to these antibiotics, many – but not all of them – die off.  A small percentage with have genetic variations that allow them to resist the antibiotic.  These survive, and grow in numbers to become the predominate strain.  Nature pushes back.

I believe this concept applies to organizations as well.  Organizations must respond to environmental pressures in order to survive and prosper.  Legislation, social and economic pressures, customer requirements, and competitive threats create the environmental context for an organization.  Those which survive are those which evolve to best deal with these pressures.  This evolution can occur at many levels within the organization, and can be observed by the shadow cast by their Enterprise Architecture.  The Enterprise Architecture evolves to respond to the environment.  A different set of environmental conditions will cause the organization to evolve in a different direction.

What if we deliberately create conditions in the environment to trigger an evolutionary response in the organization?  If we add just the right amount of stress in just the right place, the organization will evolve to fight against it.  It will develop its own antibodies.  Suppose that we want an organization to improve the way it prioritizes and funds its IT projects.  If we can introduce stress in this area, such as a set of conflicting priorities, the organization will learn from this conflict and evolve to have better project funding policies and procedures.

 This idea has some similarities to homeopathy.  According to Wikipedia, homeopathy, is:

“a system of medical practice that treats a disease especially by the administration of minute doses of a remedy that would in healthy persons produce symptoms similar to those of the disease”

 Using this approach, is it possible to antagonize an organization by poking and prodding in just the right places to get it to change its policies and procedures, SDLC, IT governance approach, and project management practices?  The challenges would be to find the correct “minute doses” that provoke the desired response, and to find the right “remedy” to use in a controlled environment.  You might not want to do this in the real world, but it does make for an interesting thought experiment!

Several months ago I found a copy of s+b on the table of my Edmonton hotel room.  Inside was a jewel of an article by Sally Helgesen on The Practical Wisdom of Ikujiro Nonaka.  Early in the article Nonaka, an expert in the field of Knowledge Management, points out that Knowledge Management is different than other aspects of IT management:

“Companies and leaders who treat knowledge management as just another branch of IT don’t understand how human beings learn and create,” he says.  Unlike land, capital, energy, labor, and technology – the conventional “inputs” into business practice – knowledge is innately self-renewing.  “It is produced and consumed simultaneously.  Its value increases with use, rather than being depleted as with industrial goods or commodities.  Above all, it is a resource created by humans acting in relationships with one another.”

Helgesen does an excellent job of describing Nonaka’s concept of creating knowledge through a cyclical interaction of tacit and explicit knowledge, and how this interaction drives innovation within an organization.  What struck me was how this concept applied to Enterprise Architecture and the journey of self-discovery and continuous improvement in service delivery!

Tacit knowledge is not written down.  It is based on personal experience, observation, and gut feeling.  It can be a difficult thing to put your finger on, as it is unspoken and not formalized.  It is instinctive knowledge, and represents an innate, almost subconscious understanding.  Explicit knowledge, on the other hand, is structured and formalized knowledge that can be attained through academic study.  Explicit knowledge allows us to apply a learned theoretical concept to solve a real-world problem.

What I found interesting about this article was Nonaka’s description of how tacit knowledge is turned into explicit knowledge through a cyclical process.  This approach is driven by social interaction of human beings as they gain tacit knowledge through personal experience, convert this knowledge into formal ideas and language, combine this knowledge with other explicit knowledge, and apply and internalize this new knowledge.

These stages reinforce one another. Nonaka quotes Katsuaki Watanabe, president of Toyota, as saying that “it is the continual dynamic synthesis of actual experience and abstract expertise [meaning tacit and explicit knowledge, respectively] that enables an organization to sustain innovation.”

There are parallels here to developing Enterprise Architecture maturity.  Organizations developing an EA program must go through a process of self-discovery.  This requires extracting the tacit knowledge within the organization and converting it into explicit knowledge.  This journey follows Nonaka’s knowledge creation process.  The conversion of tacit knowledge into explicit knowledge allows an organization to apply this knowledge to improve operational efficiency.  It is important to realize that the cycle does not end with explicit knowledge – it is the interaction of explicit knowledge with tacit knowledge creates an atmosphere for innovation, creativity and self-improvement.

Another concept presented in the article is that of ba.  Ba is an environmental context for the open flow of ideas within a group of people that enables knowledge creation.  Helgesen sums up:

Ba is never solitary; it exists among two or more people. As Nonaka says, “In ba, there is no you or me, there is only us, sharing a here-and-now relationship.” Ba can occur in a work group, a project team, an ad hoc meeting, a virtual e-mail list, or at the frontline point of contact with customers. It serves as a petri dish in which shared in­sights are cultivated and grown.

Advances in Enterprise 2.0 and social computing technologies provide opportunities for social interaction that transcend traditional physical and temporal boundaries.  This type of ba lacks the face-to-face interaction of real-world personal contact, but enables communication and collaboration among individuals who might not otherwise be able to meet in person.  The ba provided by social computing will increase collaboration and the creative flow of ideas, and create additional possibilities for innovation.  I am sure Nonaka would have more to say about this, and I can’t wait to learn more!

Quoted sections reprinted with permission from strategy+business. Published by Booz & Company.  http://www.strategy-business.com/press/article/08407?pg=0

I have seen a lot of good work being done in Enterprise Architecture over the last several years, and I am encouraged that many organizations are embracing a more holistic view of the way they deliver their business services.  Enterprise Architecture is not about technology.  It is not about applications, servers, or databases.  It is about aligning all aspects of the business to improve the quality, agility, and cost efficiency of delivering business services.

But what does it mean to be aligned?  When your car’s wheels are aligned, they all point in the same direction and work together to propel the car forward.  All of the wheels agree on the direction in which they should be moving.  For an organization, alignment means that people, process, and technology elements of the business must all work together to move the business forward.  To accomplish this, they must all agree on what “forward” actually means.  Alignment requires that these elements of the business share a common vision for the future.  And, to move anywhere at all, they have to know where they are to begin with.

But as we all know, business and IT have been historically misaligned.  In fact, there is often a huge gap – a great divide – between business and IT.  How, then, does an organization go about aligning them?  Clearly, some sort of change has to take place, but where does one begin?  Aligning business and IT requires not only that they share a common vision for the future, but that they also share an understanding of the current state.  Lao Tzu said in The Art of War that “Knowing others is wisdom, knowing thyself is enlightenment.” It is this enlightenment that enables  organizations to make the right changes to increase alignment.  Day by day.  Week by week.  Year by year.

It can be tempting to get so caught up in trying to understand and document the current state that “analysis paralysis” sets in.  How much knowledge is needed to make progress?  How soon can the first step be taken?  It is important to recognize and embrace the continuous improvement nature of aligning business and IT.  This notion should be a fundamental, underlying theme of any Enterprise Architecture program.  You need just enough information to be able to make decisions about what to change to get you in the direction of where you want to be.  Too much navel gazing and fear of moving in the wrong direction will prevent any progress from being made.

It is also worth noting that the future state never actually arrives.  The future is constantly, well, in the future.  It is important to continually readjust the long-term vision to include new factors that influence the business.  This is like having the wheels on your car realigned.  Just because they were aligned last year doesn’t mean they are still aligned after a winter worth of potholes.

As Yogi Bera said, ”You’ve got to be very careful if you don’t know where you’re going, because you might not get there.”

Tags: Enterprise Architecture, Business, IT, alignment, incremental

I have been giving a lot of thought lately to the challenges of creating shared services in an enterprise environment.  Shared services remove redundancy within the application portfolio, reduce development and maintenance costs, improve time-to-market for new applications, enable consistency of service delivery, and increase the overall quality of the applications using these services.   They form the foundation of a service-oriented architecture (SOA), and bring agility to the organization.

I want to pick on one specific obstacle to the creation of shared service: siloed project funding models.  There is an interesting parallel between siloed funding models and the classical Prisoner’s Dilemma problem: both result in a sub-optimal solution.  In the classical prisoner’s dilemma, two suspects are arrested and separated for interrogation.  Each is offered the same deal: testify against the other or remain silent.  If one prisoner testifies against the other and the other remains silent, the first one goes free and the other receives a 10-year sentence.  If both testify against the other, they each receive a five-year sentence, and if both remain silent, they each receive a six-month sentence.

No matter what decision the other prisoner makes, each prisoner is better off testifying against the other as they will receive a shorter prison sentence.  That is, if prisoner A remains silent, prisoner B will go free if he testifies against prisoner A, but will get six months if he remains silent.  If prisoner A testifies, prisoner B will get five years if he testifies, but will get 10 years if he remains silent.  The payoff for testifying is always greater than for remaining silent.  Or is it?

Using the above logic, both prisoners testify against each other and receive five-year sentences.  Somewhat paradoxically, if both prisoners remain silent, they will each only receive a six-month sentence.  But I just told you that each prisoner would be better off, regardless of what the other prisoner chooses, if they testify against the other prisoner.  Thus the dilemma.  The optimal solution can only be achieved if each prisoner trusts the other to remain silent, and remain silent themselves.

In a similar way, some organizations have funding models that give control over project selection and spending to each line of business, with no incentives to drive cooperation or horizontal initiatives.  This can present a significant challenge for the development of shared services. Shared services are more costly and take longer to build than proprietary services. More people have to be consulted.  More thought has to be put into the design to meet the requirements of all stakeholders, and more time has to be spent on security, reliability, scalability, SLAs, etc….  Over the long-run, these costs are recovered through software reuse, reduced maintenance costs, and increased quality.  Just as with the prisoner’s dilemma, the optimal solution can only be reached through trust and partnership.

I am excited that “service mash-ups” has been selected as the theme for this year’s GTEC conference.   In fact, there is a lot about mashups to be excited about.  They extend the capabilities of an organization and provide a platform for productivity which challenges traditional roles, responsibilities, and boundaries.   Mashups fill a need that is not met: if the current application portfolio did everything that was needed, we wouldn’t need mashups.  Mashups shake things up and fill this gap. And what’s not to like about a good shake-up?  Mashups symbolize a shift in the landscape for productivity within an organization.

Mashups have a lot more to do with enterprise architecture than might immediately meet the eye.  They are all about reusing existing IT assets, optimizing service capabilities of the organization, aligning IT with business, and delivering control of creating solutions directly into the hands of the users of these solutions.   In this way, mashups can play a key role in the enterprise architecture of an organization.

There are two striking ways in which mashups change the landscape for productivity: ease of assembly of software solutions, and change of responsibilities for software development.  Mashups provide an environment for rapidly building new solutions by leveraging existing data sources, processes, and user interface gadgets.  These assets can be quickly and easily orchestrated to form a new solution, often used in a context beyond their original intent.  This greatly extends the capabilities of the organization and provides a platform for a level of productivity previously unseen.  These solutions can be created by anyone – not just the IT department – and do not follow the same protracted lifecycle for the delivery of “official” applications.  This type of opportunistic programming is a new concept for most organizations.

Mashups also represent a change in the way IT is viewed within an organization.  Given this shift, it is important to recognize the role that traditional IT plays in enabling a mashup platform in the first place.  You can only mash what you have at your disposal.  Items to be mashed must first be defined and wrapped with a formal interface.  Someone, somewhere, will have to do this work.  For now, this work remains firmly within the IT department.  It is the job of architects and developers to build the underlying building blocks of the mashup platform.  These building blocks, or services, are then exposed in the “formal” environment for use in mashups.  If this sounds to you like a service-oriented architecture (SOA), you are bang on the money.  We can greatly improve our efforts in the mashup arena by taking clues from the world of SOA.  After all, if we are shaking things up, let’s do it right.

Welcome to my GTEC blog.  This is the first in series of brief articles that will present some of the key concepts behind Application Portfolio Management (APM), Project Portfolio Management (PPM), and Enterprise Architecture.  Over the course of this series I will touch on a number of topics centered on enterprise architecture and application portfolio management, including, federated CMDBs, distributed application architectures, communication and stakeholder involvement, risk management, IT governance, application lifecycle management, and architecture transformation.

I will begin this series with a brief description of application portfolio management and its benefits, and describe an approach to continuously review and improve the application portfolio within an organization.

APM and PPM are rapidly growing areas of IT management, as organizations turn their thoughts towards reducing costs, improving business and IT alignment, and increasing business agility within their organizations.  Today, as much as 75% (or more!) of an organization’s IT budget is spent on routine maintenance activities – just keeping the lights on for existing applications.  That leaves only a small portion for new application development.

APM and PPM give management the tools they need to make strategic decisions about what work should be done, which projects to fund, and how to improve their existing applications to better meet business and IT objectives.  These tools encourage a holistic view of the enterprise, and focus on deriving business value through IT.

The key concept behind APM is that you cannot manage what you do not measure.  Stated a bit differently, you cannot control or improve what you do not know.  Application Portfolio Management is about gaining an understanding of all of the applications within your enterprise, and helps to reveal risks, opportunities, patterns, and trends within the portfolio.  This information allows senior management to establish corrective action plans at the enterprise level and make strategic investment decisions to enable IT to better meet business objectives.

Let’s have a look at what is required for effective APM.  A definitive and authoritative registry of applications is needed as the base for APM.  Most organizations have multiple lists, and these lists will most certainly not agree with each other.  They all present a partial picture of the enterprise.  Application development has their list.  Operations has a different list.  The legal department has still a different view.  These lists are maintained by different groups, each with a vested interest in one aspect of application management.  The names and application properties used by these different groups will most likely be different, and this can be a difficult problem to reconcile.  We will talk more about this later when we discuss federated CMDBs.

The second thing that is needed for APM is a means by which to measure application metrics.  I suggest a set of metrics to create a balanced view of application qualities.  Metrics can be gathered in Technology, Operations, and Business areas.  There is no magic set of metrics that should be collected – the rule of thumb I use is that they should be a) readily available, or b) easily obtainable at a low cost.  If few metrics meet neither of these conditions, a separate initiative to establish quality control measures, and supporting metrics, may be advisable.  We will discuss metrics and measurement in greater detail throughout this series.

After collecting the metrics for each of the applications in the registry, it is now possible to put together a “portfolio view” of the applications within the organization. This view can be sliced and diced by technology platform, line-of-business, cost, or just about any other dimension that you care to measure.  This provides the basis for portfolio analysis, which will expose risks, opportunities, and patterns within the portfolio.

Action plans can then be established at the enterprise level to address the findings of the portfolio analysis.  For example, it may be discovered that applications written in PL/1 have greater difficulty hiring and retaining skilled resources.  This may result in an HR initiative to attract and retain resources with these skills, a service contract with a third-party vendor, an executive decision to rewrite PL/1 applications in a different language supported by the organization, or a blend of the above.  The decision is made with the entire portfolio and organization in mind.

Finally, by reviewing the portfolio on a regular basis, it becomes possible to track changes through time in the portfolio.  Maintenance cost and quality (as measured through incidents and defects) are good indicators to track.  Three two five measurement points at regular intervals will provide a good trend indicator.  The release cycle within your organization will help determine a meaningful interval, and may also provide a convenient opportunity to collect additional metrics about these applications, such as financial data for the period.  Reviewing quarter-over-quarter or year-over-year trends can highlight areas of risk before they bubble, and provide the organization with an opportunity to proactively address these risks.  For example, if a group of applications in one line-of-business have experienced an exponential increase in maintenance costs for two years in a row ($10M, $12M, $16M), this could point to an underlying problem, such as high design complexity or lack of agility of these applications to meet new or changing business requirements.  Effective Application Portfolio Management is made possible through this in-depth understanding of the individual applications and how they contribute to the enterprise portfolio.

Next week: bottom-up vs. top-down