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

Most of you have no doubt felt the aftershocks of the Service-oriented architecture (SOA) Obituary (http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html) posted earlier this year by Anne Thomas Manes.  This post created a huge chain reaction in the blogosphere, with people on both sides of the fence chiming in.  This idea gained momentum as it circled the globe, but it also got people thinking about the true value proposition for SOA.

SOA had been largely touted by hardware and software vendors as a silver bullet with the promise of transforming your enterprise into a lean and mean machine.  Cost savings, agility, and quality would pour from the goblets of those who embraced it – right out of the box!  New business partners?  New business services?  New business model?  No problem!  SOA to the rescue!

This is reminiscent of a magic diet pill which promises to let the pounds melt away while you sleep.  Exercise?  No need!  Even enjoy same foods you currently eat!

What seems to have been conveniently overlooked in this positioning of SOA is that it is not something you can buy.  SOA is a set of architectural principles that address difficult, real-world problems.  People often talk about SOA implementations, SOA initiatives, or SOA projects.  What they should be talking about is “adopting SOA principles” instead.  SOA is not a solution, it is a set of principles.  In order to get to solution you need to implement these principles.  And, of course, to get to a solution, you need to solve your current problem.

And what better place to start than the existing application portfolio – a pain point for any large organization?  The main problem here is that you have to play the hand you are dealt.  If you start with a complex environment of legacy applications with an intricate web of dependencies and relationships and hope to fix it overnight you really are going to need a silver bullet.  SOA is not a magic diet pill. Critical to the success of an SOA implementation is a disruption to the status quo. Anne makes this point nicely in her blog:

“Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.”

SOA requires a disruption of the status quo.  How true.  It is precisely because organizations have woken up and realized that the status quo is actually not working that they need a change from it.

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.

Business doesn’t stand still.  It is dynamic and constantly evolving to keep pace with changing times.  Changes in society, market opportunities, competitive threats, and legislative requirements all influence the direction of a business.  The business must be agile enough to address these pressures to stay competitive, or in some cases, just to stay alive.  This means the whole organization.  The organization needs to respond as a whole, like an organism (ever notice these terms have the same root word, organum, meaning “instrument or organ”?), to evolve organically with changes in its environment.  The speed with which the organization is able to respond to these changes can be called the agility of the organization.

How can this agility be improved?  Elements from Business (business objectives, policies, strategies), Technology (computer systems, infrastructure), and Operations (people, procedures, efficiency of execution) combine to fulfill the delivery of business services.  The alignment of these elements, and their ability to work together as a whole, dictates the efficiency by which the organization can delivery its services.  The IT systems which automate or support the delivery of these services must therefore be aligned with these business, technology, and operational elements.

Application Portfolio Management will help measure and align these elements to improve service delivery.  Begin by creating a balanced view of each application in the portfolio.  Each application should be assessed against an agreed-upon set of metrics covering business, technology, and operational elements.   This will provide a well-rounded view of the overall health of each application, and will reveal strengths, weaknesses, trends, and patterns among applications within the portfolio.

Application portfolio management is not a one-shot deal.  It must be a sustained and continuous endeavour, to continually monitor and actively manage the applications within an organization.  This will ensure that the portfolio has the right amount of agility and quality at the right cost.  Agility just for the sake of agility is an expensive undertaking.

Because of the ongoing nature of APM, it is a prime candidate to be driven by a continuous improvement process, such as Six Sigma’s Define-Measure-Analyze-Improve-Control (DMAIC) process, shown below.  You can use any continuous improvement process.  The key point is that the portfolio needs to be continually monitored, and an ongoing formal process with a feedback loop is the best way to do this.

The APM process described above measures metrics in business, technology, and operations.  The continuous improvement process must ensure that the relevant stakeholders are engaged throughout the process, that the proper metrics are collected and analyzed, and that senior management is provided with the right information to make strategic decisions to improve the performance and alignment of the application portfolio with business strategies and objectives.  To be effective, the continuous improvement process must have a way of creating action plans to address the findings and recommendations resulting from the analysis of these metrics. This is done during the “Improve” phase of the DMAIC cycle.

It is important to realize is that all parts of the organization are vested stakeholders in the successful delivery of services.  Application Portfolio Management is not just about the applications.  It is about how well these applications align with the overall organization.  Just as we collect metrics from business, technology and operations, the resulting portfolio action plans should address improvements in each of these areas.  For example, a portfolio analysis may reveal that there is a shortage of resources with a particular technology skill, such as the PL/1 programming language.  A multi-pronged action plan to address this problem might include human resource initiatives, such as hiring and training programs, policy initiatives to consider outsourcing PL/1 application development and support, and technology initiatives, such as converting PL/1 applications to a new language platform.  These are just some of the possible action plans.  Each risk identified in the portfolio analysis will give rise to additional action plans.

Risks and patterns revealed during the portfolio analysis present symptoms of one or more underlying problems within the portfolio.   A recurring theme of lack of availability of resources with technical skills may highlight other underlying problems, such as a reliance on outdated technology, or problems with staff hiring, training and retention.  It is important to treat these underlying problems, and not just the symptoms.  Action plans should not be spun off in isolation from one another, as this may result in money being spent in the wrong place on the wrong problem.  These action plans work together to form an enterprise-wide strategy to mitigate risk, reduce cost, and improve performance of the application portfolio.  The iterative, continuous improvement nature of this approach allows the organization to establish a rolling, multi-year strategy to improve service delivery and agility.  This is the real value of APM.

You cannot manage what you do not measure.  This seems to be a recurring theme here, and that is really what APM and PPM are all about.  How many applications does your organization have?  Who uses them?  How much money is spent on maintenance, development, and operational support?  What programming languages are they written in?  How are the applications related to each other?  What parts and pieces constitute each application?  For many organizations, these are surprisingly difficult questions to answer.  But they shouldn’t be, and they don’t have to be.  Basic asset management principles are easy to employ to help manage the application portfolio.  An application registry forms the basis for effective application portfolio management.

The concept of asset management is not new. Thousands of years ago, shepherds watched over their herds of sheep.  They constantly surveyed the landscape for threats and enemies.  They knew how much food and water the herd needed, and made sure they were getting enough.  They watched for births and deaths, and looked after the health of each sheep in the herd.   They had an understanding of the overall state, count, and wellbeing of the herd.  And, of course, they kept all of this information in a database, or at least they would have if they could.

The application registry is a modern-day equivalent to the shepherd’s database.  Organizations who have adopted ITIL will refer to this registry as a configuration management database, or CMDB.  The registry keeps essential information on all of the IT assets within an organization, including hardware and infrastructure details, software configuration and interdependencies, budget data, quality data, a detailed technology profile, transaction volumes, service level agreements, etc…  It is the central and authoritative source of information about these assets.

This is very difficult to pull off.  The fact is that different parts of the organization are responsible for each of these areas.  Each of these groups manages their own area, but in most organizations there is a lack of higher-level coordination between these activities.  Each group has their own view of the world, which is not necessarily in agreement with the views of the other groups.  Thus, each group may have a different list of applications, with different names, gaps, and conflicts with the other groups.  These lists can even track information at different levels of granularity, which make the problem even more difficult to resolve.  And, in the end, each group is the owner of their own information.  It is a real challenge to build a holistic view of the enterprise.

The solution is to create a federated view of these diverse registries.  This is notably different from a central, single master registry.  To help build a holistic, enterprise view of the application portfolio, you need a way to link these separate registries and resolve data quality issues.  First, establish a central authoritative master list of applications and have all stakeholders rally around this list.  This means that all groups must agree to use the names and ids from master list.  Each group must respect the boundaries of information ownership, and avoid duplicating data for which another group is responsible.  Establish links between these information sources to create a real-time, federated view of the application portfolio.

The application registry is the key integrating and unifying force used to create a federated application portfolio view.  It is very important to establish clear governance processes around maintaining the application registry, and to include the registry in internal processes impacting the application portfolio.  This includes the budget planning cycle, PMO activities, software development, release management, incident and problem management, application lifecycle planning, etc….  This will make sure that the registry is as accurate and up to date as possible.

Next: Communication is a Key to Success

So, what is an “application”, anyway?  This is an important question, because it is impossible to count what you cannot define.  In the old days this was an easy question.  Applications had clear and definitive boundaries.  They were singularly responsible for fulfilling a set of business requirements, did everything for themselves, and did not talk to anyone else.  These were the days of monolithic applications.  User interface, business logic, and data services were created, compiled, tested, and deployed as a single unit.  Any update to the application, no matter how small, required recompilation, retesting, and redeployment.  Yikes!  I can see why we don’t do that anymore.

Today all of that has changed.  For the better.  Today, applications can be composed of several distributed components – sometimes thousands – scattered across the infrastructure of an organization.  Small pieces of code are created, compiled, tested, and deployed separately, which then come together dynamically at runtime to fulfill a user request or business service.  Each discrete transaction traces a different route through the infrastructure, invoking only those components required to complete the business transaction.

There are many compelling reasons to design applications this way.  Lower software development costs.  Increased software quality, security, and performance.  Reduced risk.  Greater agility.  Many of these benefits are realized through software reuse, where a single block of code is designed, written, tested, and deployed as a reusable service.  This service is now open for business, and can be used by many different applications.  The more the merrier, and the greater the savings.  In fact, an application can make use of many different shared services to deliver its functionality.

What you end up with is many applications sharing many services – kind of a “service soup” – where single “applications” are hard to nail down.  To which application does a shared service or component belong?  Is the “application” merely the collection of round-trip business transactions that are conveniently grouped together and presented through a single user interface?  Does the word “application” still make sense?

But the fuzziness doesn’t stop there. Cloud computing, ASP solutions, and external business interfaces have pushed the boundaries of an application outside the walls of the organization which they serve.  Now, an “application” may consist of parts and pieces under different domains of control.  This makes it even more difficult to pin down a definition for “application”.

As I said earlier, it is impossible to count (and manage) what you cannot define.  That is why it is essential to have a clear definition and understanding of an “application” – including its parts and pieces – to do effective “application” portfolio management.   Settle on a definition that makes sense to you and your organization, then formalize and communicate this definition to all stakeholders.

Next: The Application Registry