Skip to Content

Using TOGAF- Part2-Preliminary Phase

This is  continuation of previous blog in the context of conducting preliminary phase of TOGAF is to meet  the objectives of preliminary phase  which are  as follows:

  • Review organization context for conducting enterprise Architecture
  • To identify primary stake holders and sponsor stakeholders
  • To enable sponsor to create requirements for work across the affected business areas
  • Identify scope elements of enterprise organization
  • To define architecture footprint for the organization
  • To define framework and methodologies
  • Confirm a governance and support framework.
  • Select and implement supporting tools
  • To define architecture principles.

In order to address such objectives we have conducted  workshops with stakeholders, various concerns were raised on the current environment from almost all the stakeholders which are related to increased cost, reduced customer satisfaction and increased effort requirements. Following table summarises the current concerns and impact, which explains why defining Enterprise Architecture is undertaken as well address few of the objectives in the context of Order&Buy.

Stakeholders Concern Impact  Possible solutions 
Sponsor Huge investment made in call centre operations, application development and IT infrastructure Current economic crisis calls for cost reduction across all areas and it is mandatory to reduce the current expenses Create an Enterprise Architecture that will address current issues.
Call centre manager Different type of user interfaces for the same end user service. Call centre staff need to be attentive and not to confuse different options for different purpose. More training required for different GUI’s.  E-enable call centre operations and provide self service where possible.
Business Managers Customers end up calling call centres for most of the operations involved in Order & Buy More interaction with call centre demands more time from the customer leading to less customer satisfaction and less business.  Create similar user interface for all Order & Buy services.
Application architects Multiple platforms to develop and support applications on. More time taken in implementing changes to the existing applications. No or very less reuse of components. Migrate all applications onto a single platform.
Infrastructure architects Inflexible infrastructure running bespoke and legacy applications which cannot be upgraded to the latest technologies to reap the benefits. Increased cost and administration overhead to maintain different types of hardware and server infrastructure for different applications. Upgrade to stable technologies, remove bespoke and legacy applications and create shared services for similar operations.


High level solutions Stakeholders Actions

Migrate all applications onto a single platform.

Business analysts and application architects

Understand the business flows for various O&B operations. Evaluate and come up with a single platform to host the service. Choose appropriate vendors to provide services.

Upgrade to stable technologies, remove bespoke and legacy applications and create shared services for similar operations. 

Infrastructure architects, application architects, designers

Understand application landscape and business requirementsCreate a high level infrastructure target map

Create similar user interface for all Order & Buy services.

Call centre manager, application architects and developers

Understand the current GUI options.Come up with common GUI high level designValidate if the new set underlying technologies can support the new GUI options

E-enable call centre operations and provide self service where possible.

Ecommerce architects, application architects

Find out the current work flows, actors and actions.Analyse which actions can be E-enabled along with security requirements.Document the e-enablement requirements

 Maturity assessment  and gaps

Organisation has an already established IT team which was instrumental in developing the existing set of applications. The experience of the existing IT team can be utilized to some extent in preparing the architecture and achieving the final goals. Their experience can be used in validating the architecture and solutions being adopted, to make sure that they meet the organizational goals. The existing business analyst team can guide the architecture team in order to make sure that the business services and functions are being implemented correctly.Some of the major gaps are in the area of managing the architecture implementation, project management capabilities and restricted technical abilities of most of the IT team members (other than the architects)

Budget Requirements

The overall budget requirements for the architecture activity will be borne by the IT Department, which will be divided into cost centers focusing on certain aspects of the overall architecture process

 Architecture Principles(Broad/Macro Level) that was established and  needs to be followed are as follows;


Principle Statement  Rationale Implication

 Technology Independence

Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms

Independence of applications from the underlying technology allows applications to be developed, upgraded, and operated in the most cost-effective and timely way. Otherwise technology, which is subject to continual obsolescence and vendor dependence, becomes the driver rather than the user requirements themselves.

Realizing that every decision made with respect to IT makes us dependent on that technology, the intent of this principle is to ensure that Application Software is not dependent on specific hardware and operating systems software 

This principle will require standards which support portability.

For Commercial Off-The-Shelf (COTS) and Government Off-The-Shelf (GOTS) apps, there may be limited choices, as many of these are technology and platform-dependent.

APIs will need to be developed to enable legacy applications to interoperate with applications and operating environments developed under the enterprise architecture.

Middleware should be used to decouple applications from specific software solutions.

This principle could lead to use of Java, and future Java-like protocols, which give a high degree of priority to platform-independence.

Common Use Applications Development of applications used across the enterprise is preferred over thedevelopment of similar or duplicative applications which are only provided to a particular organization  Duplicative capability   is expensive and proliferates conflicting data Capabilities for Order & Buy unit  own use which are similar/duplicative of enterprise-wide capabilities will not be allowed. In this way, expenditures of scarce resources to develop essentially the same capability in marginally different ways will be reduced.
Data and information used to support enterprise decision-making will be standardized to a much greater extent than previously. This is because the smaller, organizational capabilities which produced different data (which was not shared among other organizations) will be replaced by enterprise-wide capabilities.

In a nutshell if i have to look into principles that were established were robust but pretty simple

Business Principles

  • Data access requires Security.
  • Common Vocabulary and Data Definition

Architecture Principles

  • Logical Separation  & Loose coupling of Components

  • Location and Time Independence

  • Common Interfaces for Applications Maintenance.

  • Flexibility to integrate the future requirements

  • Ease of Use.

 In the Preliminary phase it was quite clear that Order and Buy unit  will be the   enterprise to be considered for the purpose of developing the architecture. The main units of Order and Buy that will be affected by the architecture changes are Retail Business Marketing Team, IT Team, Business Analysts Team, Call Center team and End Customers i.e. policy owners. In addition, the release management in conjunction with IT team, Business Owners and Retail Business Marketing team decide the changes to be made to the applications as well as the timing of release of each of the changes to the applications. The existing enterprise provides different options to the end customer for buying a policy like online systems, brokers / agents, call centers. In the current scenario, online systems provide a very important way of reaching out to potential customers. IT team would need to be part of the team, as  they will play an important role in guiding the entire process from the IT perspectiveThe Business Analyst team and Retail Marketing team will also form part of the architecture team.

Moving on to Next Blog

Using TOGAF- Part3- Architecture Vision

Be the first to leave a comment
You must be Logged on to comment or reply to a post.