Enterprise Architecture

Documentation

Many businesses expend significant and increasing rare funds in creating documents supporting the design, development and implementation of initiatives that are expected to provide them with real benefit. How many of these same businesses are able to describe the both the impact and the dependencies a single initiative will have on other initiatives that are in train or in fact have been delivered.

The downside of many documents produced is that they tend to be static (point in time) rather than living and dynamic. The end game in document production is often to have it printed and then ‘signed-off’. Once in the ‘signed-off’ state the document, referred to by some as shelf-ware may only rarely be referred to again.

Businesses need to actively examine the on-going relevance of documents produced. Initiatives should be supported by an active repository that holds all relevant and up-to-date information that can be readily queried. Documents can be, with some effort, made dynamic with content being sourced/linked to the repository.

Multiple facets of business

Even the most simple of businesses would be perceived as having many fundamentally different yet inter-dependent components. Consequently it is only reasonable to expect that so should be their supporting architectures

All businesses are multi-faceted in nature with individuals generally being interested in particular, rather than all facets, at any one point in time. It is however not enough to consider the enabling technologies for a part of the business in isolation but to also examine the people, their motivations, external influencers (amongst other things) and their interrelationships when establishing a supporting architecture. Similarly it is also not sufficient to just explore the business drivers and process with looking at what the technology can delivery.

By recognising this a more complete picture of the business can be built from significant and varied knowledge bases providing increased overall value that caters for multiple needs.

Holistic Architecture: A new term replacing current confusion

Within a business it is crucial that all participants operate from a shared understanding. Consistent misuse of the terms ‘IT Architecture’ and ‘Enterprise Architecture’ as synonyms limits the scope of Enterprise Architecture reducing its value to the business. As the misuse is so widespread I suggest we adopt the unambiguous term ‘Holistic Architecture’ which brings with it no baggage.

The issue of communication is one reason why a new term should be introduced. Thomas Kuhn (Structure of Scientific Revolutions), in 1962, introduced a. concept of incommensurability. With regards to this situation the problem is the preconception that individual users have of the term Enterprise Architect. Unless they have the same definition then any communication between them will result in a mismatch of expectations. Having lost the initiative in the use of the term Enterprise Architect we should now educate others in the use of a new term rather than attempt the ultimately futile act of re-education.

Avoiding the use of the term Enterprise Architect and introducing something like “Business/IT Strategy Architect” in order to dispel misunderstanding confirms my view that an Holistic Architect is a better choice. Stringing together a number of descriptors before the word Architect tends to be a clumsy attempt to solve the problem. Architect by itself is not sufficient as it is recognised that there are many aspects of architecture which can be explored and in which some individuals may have deep skills. The use of a composite descriptor such as “‘Business/IT Strategy” also seems to reinforce the concept that an architecture is segmented. I would contend that whilst there are multiple facets to an architecture it should be regarded as an integrated whole.

Repository of lessons learned

Maintaining a repository of lessons learned is a valuable tool when assessing the viability or advisability of a newly identified business initiative. Consequently being able to make an informed decision to proceed will provide a higher level of confidence that the outcomes and benefits identified as a result of implementing the initiative will be realised. With historic data available the ability to assess risk and put in place appropriate mitigation strategies can only improve.

This repository must be actively built and maintained with relevant information. A business should develop processes that not only determine the type of information they wish to capture, including key criteria they wish to use in reaching decisions and also ensure that these processes are correctly executed.

With good knowledge of what has occurred in the past the ability to extrapolate and forecast future outcomes can only improve to the betterment of the business.

Putting Business Architecture in perspective.

Business Architecture is neither the after-thought nor the financial overhead that many within an organisation regard it as being. Whereas it is widely accepted that the development of an Enterprise Architecture enables the efficient deployment of Information Technology the development of a Business Architecture appears to be more of a mystery as to what its true benefit may be.

A Business Architecture provides support for how the vision of a business can be navigated from strategy through to execution, incorporating or perhaps integrating with the Enterprise Architecture with its predominantly IT focus. A Business Architecture can assist with the identification, the prioritisation and the development and/or maturing of capabilities and supporting processes required to realise the Business Strategy.

Without a Business Architecture the opportunity to drive a business efficiently and using scarce resources wisely is greatly diminished.

Not only is the Business Architecture not an overhead but is an essential tool in allowing a business to prosper.

Adopting an Enterprise Architecture hybrid

Most businesses engage in the creation of architectural artefacts as part of their Business As Usual process as it applies to the design and execution of strategic initiatives.

Many of these businesses will not have a supporting Enterprise Architecture Framework in place yet appreciate the value that one may bring.

Oddly enough, a significant obstacle in establishing an Enterprise Architecture is the wealth of already created material. In exploring the Architectural Frameworks such as FEAF or TOGAF the question generally arises on what happens to the architectural components that have already been developed. These have generally been socialised and accepted by the business and the prospect of ‘tossing’ them out can result in significant push-back.

One solution is the establishment of a Hybrid Architecture Framework. In this case, by aligning architectural components already developed with those supported by other frameworks, it is reasonable to expect that appropriate coverage of the architectural landscape could be made. By choosing components that maximise the reuse of an already created body of work, avoiding rework and also resonate strongly within the business and IT the perceived obstacles can be largely overcome.

Instead of maintaining a purist view to building an Enterprise Architecture, by ‘picking the eyes’ out of what is already developed and what make sense from other frameworks, the business can realise an asset to which it may otherwise have been denied.

It is much better to have an Enterprise Architecture, no matter its form, than none at all.

Missing the mark!

Having decided to engage in the development of an Enterprise Architecture within a business it is extremely important to adopt an approach to capturing and recording information that supports the decision making process.

Without an approach or methodology directing the building of the architecture it is extremely easy to expend much effort and expense building ‘beautiful models’ that contribute little to realising the overall business strategy. With the plethora of models available to be built in the many different Architectural Frameworks it is often the easier or better understood that are undertaken first rather than the most urgent.

However, with forethought and by first gaining some understanding of where the business may have issues, a series of questions that need answering should be developed. These questions, whatever they may turn out to be, can assist in focusing the architectural development in those areas that would ultimately lead, with analysis, to providing valuable answers.

By targeting the development of the architecture to support the solving of problems that the business might have, earlier rather than later, the architect can develop a life of its own and become a valuable asset. With the subsequent maturing of the architecture through asking additional questions the decision making processes becomes more reliable and wide ranging.

Without selecting an appropriate focus the architecture will more than likely miss the mark and become the ‘white elephant’ that provides no ongoing business benefit.

Enterprise Architecture and the Brownfield business.

When establishing an Enterprise Architecture within a business it is extremely rare that that the business would be regarded as being truly ‘Greenfield’. In a ‘Greenfield’ business there is no existing architectural collateral that need be considered as influencing the shape of the Enterprise Architecture. The integrity of the Enterprise Architecture Framework to be adopted, assuming that there is a preference for an ‘off-the shelf’ framework such as TOGAF, FEAF, PEAF or their variants, need not be compromised.

It is more often the case, however, that the ‘Brownfield’ business recognises that it is in need of an Enterprise Architecture in order to better manage, prioritise and shape its business initiatives so as to better serve its customers and realise its mission and strategic intent.

The Brownfield business, like the Greenfield, still needs to capture information relating to

• vision,
• mission,
• strategy,
• objectives,
• goals,
• requirements and
• external Influences

It also needs to factor in already developed

• principles,
• policies and
• existing architectural collateral (Business, Information, Application, Technology) that is likely to have been developed in a siloed approach.

When establishing an Enterprise Architecture Framework the ‘Brownfield’ business inevitably needs to take a pragmatic rather than a purist approach. Instead of being able to adopt a single ‘flavour’ of framework a hybrid is more than likely to be adopted. Being able to leverage and re-use existing collateral can kick start the entire process whilst reducing the requirement of costly re-work. It is worthwhile to resist the temptation to start from scratch.

Enterprise Architecture – why have one?

An Enterprise Architecture is an integrated, living and ever evolving business artefact that is both informed and informs other parts of the business. It takes a holistic view of both ‘business’ and ‘IT’ with business being the driver and IT an enabler. As each facet of a well-constructed Enterprise Architecture will have documented inter-dependencies it is unlikely that change in one place will not elicit change in another.

Having and maintaining an Enterprise Architecture within a business must provide some on-going value or what is the point. Understanding and acknowledging the value is paramount to its success.

Underpinning five key questions, spanning vision to execution:

• Why are we doing this?
• What do we need to do?
• What are we able to do?
• What is the impact of change?
• How do we do it?

an Enterprise Architecture provides a dynamic end-to-end view of the business, its capabilities and how it operates.

As a tool it supports, amongst many other things:

• the optimisation of return on business and IT investments by more closely aligning them with business needs,
• identification of priority areas for consolidating and reducing costs,
• identification and quantification of change impacts to support the delivery of strategic change initiatives.

As a tool, an Enterprise Architecture can provide visibility of aspects of the business that might otherwise remain obscure.

Using an Enterprise Architecture can provide a business with a means to make better decisions** relating to its future allowing it to grow and prosper.

Not having an Enterprise Architecture does not guarantee failure but does introduce an element of ‘Russian Roulette’ into any business decisions.

Creating Order out of Chaos!!

All businesses capture and store information, in some form, about:

• What they are doing
• How they are doing it and
• Why

This information may be structured but often is not. Information abounds that relates specifically to individual projects or activities that have been undertaken but not on how they related to or are dependent on others. Without structure even this information may be internally disjoint.

Where there is a lack of capability to establish, analyse and consequently understand these relationships, the decision making capability of the business will be significantly compromised resulting in:

• Guessing rather than knowing
• Being oblivious rather than aware
• Engaging in inactivity rather activity
• Engaging in inappropriate activity rather than appropriate.
• Spending recklessly **rather than **wisely.
• Failing rather than succeeding (in the worst case)

Establishing a structure where relevant information can be placed provides the capability of:

• Having an end-to-end business view of how the business operates.
• Identifying what is really important.
• Determining the real impact of change.
• Making informed decisions.
• Prioritising how and when (or if) money should be spent.

In establishing an Enterprise Architecture Framework the capability of being able to categorise, allocate and analyse information is greatly enhanced.

Governing content and measuring performance provides the opportunity of making properly informed decisions.

Creating order out of chaos: perhaps not, but the business will be better placed to succeed.

Five Cs of Enterprise Architecture

A complete Enterprise Architecture that effectively supports the business cannot be purchased as a fully realisable off-the-shelf commodity. This statement should of course be qualified by at least considering the possibility of acquiring a hypothetical ‘business-in-a-box’ with everything already defined and requiring the business to change to fit.

To be useful for the majority of businesses the Enterprise Architecture must be crafted with particular care.

As it takes time to craft well it is not reasonable to expect the business to wait until the Enterprise Architecture is fully formed. If it is to gain credibility and maintain momentum, should be used as it is being built.

To ensure that the Enterprise Architecture is indeed usable there are five key areas that should be considered:

• CONTENT: What should be included within the Enterprise Architecture and in what order should it be captured.
• COVERAGE: How much of the business should be initially covered to provide real, shorter term, value to the user of the Enterprise Architecture. Initial content captured should provide and end-to-end slice through the business.
• CONSISTENCY: Ensure standards for capturing, recording and reporting on information have been defined and are consistently applied. Information captured must also not be ambiguous or open to misinterpretation.
• CONTROL: Provide mechanisms by which information which has been captured, to be included within the Enterprise Architecture, is accurate and has been validated. On-going governance is key to the success of an Enterprise Architecture and consequently to the business.
• CURRENCY: It is crucial that content held within the Enterprise Architecture be maintained. The consumer of content must have confidence that what they see is current and has not been superseded. Unless currency is maintained the Enterprise Architecture, instead of being of value, can become a liability.

It is imperative that the Enterprise Architecture be constructed and populated with a view to support the business.

By choosing what will be be included first and then maturing the content iteratively, the business will reap maximum value earlier. With a realised value identified and quantified earlier, the Enterprise Architecture has a very real chance of providing significant and long term business benefit.

The Business does not stop with Information Technology

When establishing a business architecture all of its components must be taken into consideration. Whilst it may be tempting to ignore technology as being out of scope (by saying it will be covered within a Technical Architecture) it is absolutely essential that it be included, if only at a high level. To ignore the contribution (existing and potential) and the impact that technology has within the business will compromise the decision making process and potentially lead to lost opportunities.

As an enabler, technology provides a platform upon which many of the business’ Capabilities, Functions and Processes are executed.

Without understanding of what the technology can offer many aspects of the business could fail to materialise or could perform so poorly as to be a liability rather than an asset.

With understanding, the opportunity to increase business benefit, through perhaps increased or improved process automation, is enhanced.

When assessing the capability to deliver against its Strategies, Goals and Objectives business, awareness of what technology does and can provide, gives needed information when deciding and prioritising what is required to increase business maturity.

The business does not stop at IT but encompasses everything needed to deliver a successful outcome. IT is part of the business.

Enterprise Architecture and Agile development are not mutually exclusive.

Business driven Agile development is achieved by

• Breaking tasks into small increments;
• Applying only the minimum of planning.
• Iterating over short time frames (timeboxes).
• Involving a cross functional team working in all Software Development LifeCycle functions.

At the conclusion of an iteration a working product is demonstrated to stakeholders with the goal of minimising overall risk and allowing the development project to readily adapt to change. In defining each iteration it is essential within an Agile methodology that

• The current state of the solution landscape is reviewed.
• The desired state from the business is elicited.
• The technical and non-technical gaps between the current and target states be determined.
• A definition (Story Card) of the steps necessary to narrow the gaps is created.
• A review the implementation results is undertaken so as to choose the next step and revise where appropriate the approach towards the target state

Each of above, whilst in an Agile development is focussed on the micro, is also fundamental to a successful Enterprise Architecture on a macro scale. An Agile methodology can also be applied to the development of the Enterprise Architecture which subsequently becomes an information source for each Agile development activity.

1. Establish a light Enterprise Architecture at the highest level of the business providing. Business and IT strategy, a high-level roadmap, a light touch architecture framework, principles, guidelines and a governance approach.
2. Identify the slice of the enterprise where the business is about to embark upon multiple moderately sized initiatives.
3. Define a minimum set of end-to-end architectural artefacts such as processes, data models, service models etc. needed to support these initiatives and begin populating a repository with enterprise content, governing artefacts, and start documenting guidelines and best practices.
4. Assess the results, adjusting the previously defined governance approach, re-align the business and IT strategies where appropriate and mature the architecture framework.
5. Select another slice of the business and repeat from steps 2.

Agile development and Enterprise Architecture can work hand in hand, providing valuable support to one another.

Shaping business operations.

An Enterprise Architecture gives its user the opportunity of exploring the business from end-to-end. Instead of only having a ‘blinkered’ or ‘narrow’ view of only isolated parts of the business the user is able to gain a holistic perspective.

The ‘big picture’ view supports the ability to drive efficient and effective business behaviour.

Systems or processes that are fragmented across the business can, with an Enterprise Architecture, be better managed. Whilst they remain fragmented the business is subject to duplication, waste and lost opportunities.

Understanding what is ‘out there’ and how it is used and the impact of its use on the business provides the impetus to implement managed change.

The opportunity to take fragmented systems and with knowledge of the potential impacts explore the possibilities to

• Categorise – creating better understanding of attributes and behaviour.
• Aggregate – bringing together like capabilities, processes, functions, information and systems
• Consolidate – simplifying by eliminating redundant environments.

Ultimately, the use of an Enterprise Architecture can lead to a rationalised business operations environment that is better placed to compete in the market place.

Guiding Principles.

An Enterprise Architecture, supporting a business, is an extremely valuable asset. It is however very easy, when populating it with knowledge garnered from the business, to use it as a dumping ground for everything: ‘just in case it becomes useful’.

Potential content, before being incorporated within the Enterprise Architecture repository, should be subject to a number of tests to determine its ‘fitness for purpose’

Establishing a set of Guiding Principles and ensuring that they are adhered to, provides a mechanism through which the Enterprise Architecture can retain its on-going value.

Content to be included should be:

• Strategic: Align the architecture with decisions that need to be made and the strategic vision of the business
• Standards Based: Reducing needless diversity
• Simple: Making things as simple as possible but no simpler. Following well defined patterns and blueprints to define the content will increase understanding and decrease complexity.
• Knowledge Driven: Manage content as a single source of truth for others. Base the content on facts, not supposition or assumptions.
• Reliable: Ensure the validity of ‘facts’ and avoid inconsistencies.
• Accessible: Content needs to be available to those who need it.
• Secure: Ensure confidentiality, integrity and currency of information.
• Sustainable: Content to be included must be maintainable, manageable and measurable.

The application of Guiding Principles, as a test for content inclusion and a governance regime providing assurance that they are being followed, will ensure that the Enterprise Architecture will provide a tool to the business that is worthy of its investment.

Decision making with finesse

So often, problems are ‘solved’ within a business by using the ‘bull-dozer’ approach of throwing money at them or cutting resources.

If there is a problem with performance get a bigger box.

Costs are too high, let’s get rid of people.

I frequently hear the phrase ‘Work smarter, not harder’ but whilst seeing this applied by rare individuals I hardly ever see it applied at a corporate level.

An Enterprise that has a culture of ‘Working smarter’ will apply finesse to a problem not brute force. It will analyse root causes to a problem to find out ‘Why’ then leverage corporate knowledge and wisdom to determine ‘What’ and ‘How’.

A well-considered response to a problem will always be preferable to the gut reaction.

Risks, information and decision making

Without having visibility of the whole enterprise and the inter-relationships between its various components how can the true risks associated with a business initiative be reliably determined. With risk not fully identified how can you establish the cost of mitigation?

It is essential if risk is to be assessed that the business is provided with both necessary and sufficient information from which to work. Without access to this the decision making process will be subject to higher levels of uncertainty than is essential.

‘Quick Wins’ and lost opportunities

It is often the case that a business will pursue the ‘quick win’ when presented with a number of initiatives. That they do so seems on the surface to be logical as there is a fair chance that they will get an early return on investment thus seemingly validating the expenditure of increasing scarce funds.

Relegating other initiatives to the ‘back-burner ‘, to be looked at a later stage, may just however been closing the door on opportunities that far out-perform, in the longer term, than the ‘quick win’.

It can be all too easy to be essentially blinkered and not looking at the bigger picture or for the longer term to avoid making the ‘harder’ but wiser decisions. By setting the decision horizon or ‘pay back’ period to a point in the too near future the opportunity to reap real and significant benefit may be delayed unnecessarily or totally missed.

Satisfying wants and needs

The trouble with determining not only what the business wants but what it actually needs in order to deliver on its business strategy, if one exists, is an obstacle that absolutely must be overcome. All too often a business has vague idea on what it wants or needs to do. It may or may not have a good understanding of the business drivers but frequently little understanding how to best arrive at a solution.

Being able to clearly elucidate the scope of the problem to be solved and to define a set of requirements that would need to be satisfied to guarantee that a solution had been delivered is both necessary and essential.

Without a clear problem statement and associated requirements the opportunity to be delivered a solution that does not satisfy the need escalates dramatically. Without appropriate directions being defined the probability of frequent change being requested during the course of building a solution increases.

Applying rigour at the point where the problem is being defined and maintaining proper processes throughout the solution definition will result in better business outcomes and less frustration for both the business itself and the problem solvers.

Decision making and self interest

The relationship between the making of rapid, short term and often ill-conceived decisions and that of receiving financial incentives (bonuses or commissions) should be explored.

How often is a decision to proceed with a purchase or the execution of an initiative made with the expectation of the decision maker of receiving some personal and immediate financial benefit? Decisions made with an eye on the personal, even if unconsciously done so, rather than for the corporate long term benefit, are inherently flawed.

Sales commission based on the usual Sales Value rather than the rarer Delivered Margin encourages over-selling and under-delivery.

Decisions to deliver a project on time and (apparently) on budget at the expense of quality, governance and testing might provide kudos and perhaps a bonus for the Project Manager but will possibly cause significant ongoing issues when the project has wound up (having been delivered) and it has entered a Business As Usual phase.

All decisions should be made with an understanding of their longer term impact. Perhaps as well as offering incentives there should be the opportunity to offer disincentives as well.

Supporting agility in decision making

It would be naive to expect that when running a business that decisions would not need to be made. Situations are constantly arising that will require a response. To be able to reliably respond, appropriately and with some degree of agility, can determine whether a business will ultimately succeed or fail.

Examples of situations that need responses are:

• Changes in Government regulations which require compliance.
• New service offerings by competitors, potentially ‘stealing’ market share.
• Changes in business strategic focus.
• Innovation, introducing new business opportunities.
• Failure of process or systems to deliver required results.

The decision making process needs to be as agile as possible so that an appropriate response can be adopted both rapidly and executed efficiently.

Too often, however, the decision making process takes too long to be effective or, though lack of good information, is poorly formulated.

The business, with a well-structured, content rich and properly maintained Enterprise Architecture, has an asset that supports decision making with many touch points into the process.

The Enterprise Architecture, providing an end-to-end repository of knowledge about the business, can provide a single access point from which information relevant to the situation can be drawn.

The Enterprise Architecture can additionally support the analysis and development of decision options and assist in the assessment of the business and/or technical impact of each. With a good understanding of impacts a decision can be reached and appropriate activities developed through which the decision can be executed.

Lastly the Enterprise Architecture repository can provide a framework which could capture the quantitative outcomes of decision made thus feeding and maturing future decision making activities.

Without having access to an active Enterprise Architecture the decision making process, whilst going through the same steps, can take significantly longer. Also being affected by poor access to information and consequently to a diminished ability to carry out a timely impact analyse the quality of decisions may be compromised.

It is often said: “Knowledge is Power”

An Enterprise Architecture is a repository of business knowledge. With it the power to make ‘good’, rapid business decision is greatly enhanced.

Having agility in the decision making process and making consistently good decisions must be good for the business.

Managing the impact of risk on business decisions.

Risk that is not understood can present as much or more danger to a business than one which has not been foreseen.

All decisions will have some element of risk associated with them and how the risk is to be ultimately managed can shape the actual decision itself.

Risk can be effectively managed ONLY if it is understood.

Understanding can only be realised with sufficient information available to provide appropriate context to the risk in relation to the decision to be made and the potential impact it will have on the business.

An Enterprise Architecture, whilst not pretending to be omniscient, can provide the necessary information to assess the risk and for the decision maker to garner enough understanding of both its impact and likelihood of occurring to formulate an appropriate decision and possible mitigation.

The information held within the Enterprise Architecture repository may not be complete when tasked to assist in supporting any given decision but will be better than not having any at all.

The outcomes of decisions, made as a consequence of the understanding reached about specific risks, should be fed back into the Enterprise Architecture improving future risk assessment.

With even better information new risks can be better understood with the business benefiting from better decisions and less unintended consequences.

Business success – It’s all about choices

No business is an automaton whereby, once started, it will continue to operate unsupervised. It will always be the case that situations, either internal or external, will arise or can be anticipated that will require the human element to provide appropriate and timely responses. Any response, if it is to be in the best interests of the business, will always involve the making of a reasoned choice.

• Will I or won’t I do something?
• What are the options open to me?
• Why would I choose one option over another?
• What order should I do these in?

In making a choice between competing options it is essential that sufficient information be available. With insufficient information the choice made may not be optimal. Equally important is having sufficient information so that an identification of appropriate options can be made.

An Enterprise Architecture is a repository of information that can be used to both identify options and then support the choice of selecting between them. With the gathering of suitable measures on how the business operates an analysis of the impact of adopting one option over another can be made.

The ability to provide a quantitative assessment of the merits of one choice over another, whilst also being able to explore the effect of its selection across the business, increases the confidence that the ‘right’ choice will be made.

Running a business is all about choices. Having and maintaining an Enterprise Architecture maximises the chances that the choices made will be in the best interests of the business.

Choosing appropriate solutions to address problem situations.

There will always more than one way to solve any given problem. How effective any given solution will be will depend on what information was used in the solution’s definition. An Enterprise Architecture can provide a repository of useful information necessary to the successful formulation of a problem’s solution.

By itself this is not enough. A business situation will always require some response even if only choosing to do nothing. Those charged with its resolving the situation will undoubtedly identify a number of options from which to choose.

How they go about identifying and subsequently making their choice will shape the eventual impact of the option selected. The Enterprise Architecture, whilst holding valuable information, must be supported by processes assisting its user to find and use the information that they require. The is nothing more frustrating than knowing that information exists but not being able to locate it.

Without supporting processes the user of the Enterprise Architecture may just as well be reaching into a ‘lucky dip’ and see what comes out.

The information returned by a ‘hit and miss’ approach may be accurate, assuming the Enterprise Architecture content is properly governed, but will it be relevant and appropriate.

Processes supporting an Enterprise Architecture can assist in assessing the validity of using the returned information to the situation at hand.

The information held within the Enterprise Architecture repository is not enough, by itself, to provide significant value to the business. It must be supported by processes assisting the user to leverage the information to solve real problems in the most optimal fashion.