Enterprise Architecture

Enterprise architecture

Author

Author Affiliation

Date

Enterprise Architecture

Table of Contents

1. Enterprise architecture definition

2. Enterprise architecture Level function a. Conceptual levelb. Logical level

3. Review of industry trenda. Bio datab. Data analysisc. Consumerizationd. Mobilitye. Context aware of ITf. Cloud Computing 

4. Six Phases of enterprise architecture

5. Application of enterprise architecture

6. Future development of enterprise architecture

7. Benefit of enterprise architecture

8. Customer relationship management introduction

Enterprise Architecture

Enterprise Architecture

1. Definition

Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.

The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them.

Reference http://www.gartner.com/it-glossary/enterprise-architecture-ea/

What is Enterprise Data Architecture Responsible for?

An EDA is responsible for providing a consistent strategy for

conceptually,

logically, and

physically governing (i.e., uniquely defining and organizing) the data that defines an enterprise

An EDA is foundational to an enterprise IT architecture

2. Enterprise Level function

At the enterprise level , the root of the Function Chart may contain the name of the organization (or a major function or sub-function within an organization).  The root is broken down into no more than three levels of detail.  A brief description is provided for each function.

Enterprise Architecture

The second level identifies major business functions, typically related to Planning, Execution, and Control.

Note that administrative functions such as Finance, Accounting, and Personnel should not be top level functions.  Top level functions should only be functions that directly contribute to the production of an organization's product or service.  Administrative functions should only be further decomposed if required, for example, if a system is being developed to support administrative functions. Because Function Charts read so similarly to Organization Charts, i.e., both use a top-down structure, it can be politically very difficult to convince the Corporate Vice President of Finance and Personnel, for example, that his or her function is not a top level function.  One method of addressing this is to draw separate Function Charts for each of the administrative functions so that each has its own top level Function Chart.  This does not take much time, gets these functions included in the documentation, and works well as long as the charts are not further expanded.  Another method of addressing this is to include administrative functions under a function called, for instance, Organizational Support.

a. Conceptual Level of Detail

Enterprise Architecture

 

At the conceptual level, leaf level functions (i.e., lowest level functions) on the enterprise level chart within the context of the system are decomposed into the next level of detail.  This level identifies the major business processes necessary to accomplish each function.  Processes identified at this level typically correspond to application systems or sub-systems, for example, Sales, Finance, or Purchasing.

Functional Decomposition at the conceptual level of detail helps define the scope of a project.

b. Logical Level of Detail

At the logical level , the Function Chart decomposes processes into the lowest level of detail.  Functional Decomposition at this level identifies all the processes within the scope of the project.  The lowest level processes on the Function Chart can be documented using Action Diagrams, Structured English .

Enterprise Architecture

Once started, leaf level processes must continue to conclusion or else be totally undone.  A leaf level process takes the business from one state to another or does not change the state of the business at all.  To complete Functional Decomposition, each branch of the tree must be decomposed to the lowest level process.  However, not every branch will be decomposed to the same number of levels.

 

Complete understanding of the characteristics of a leaf level process requires an understanding of:

 

·          volume and response time requirements, i.e., determine how often and how quickly a response from the process is required,

 

·          security, i.e., determine who performs what processes,

 

·          design menu structures, i.e., determine what user groups use what processes,

Enterprise Architecture

 

·          plan for distribution, i.e., determine the geographic locations where the processes are performed.

Reference

http://it.toolbox.com/blogs/enterprise-solutions/levels-of-detail-for-functional-decomposition-14626

3. Review of major industry trends :

In this light, the enterprise architect will scan the industry analysts, the trade journals and the vendors for ideas and trends.  Here is my short list of six trends for 2012:

1. Big Data – Databases of large magnitude are not uncommon anymore. I recall discussions at client sites only ten years ago lamenting how hard it was to handle terabytes of data. The physical constraints and cost of storage per unit is declining, and now we speak of exabytes and zettabytes of storage.  The data isn’t just traditional databases of the 3rd normalized form, but unstructured

Enterprise Architecture

data, email, video, mobile, and much more.  Your future state architecture should consider tools, methods and infrastructure to support initiatives like access, de-duplication, appropriate backup and recovery, and retention strategy. Analytics and social media are a huge part of this. [Note to EAs: well-informed Information Architects are going to be your new best friend on this one.]

2. Data analytics – This adjunct to the big data discussion highlights the growing demand for data analytic tools, process, and access to data that has not been traditionally accessed.  Not only is the structured data valuable for analysis, so is what you can glean from social media or combinations of your data silos, marts and warehouses in the organization. If your cloud strategy is in place, have you considered providing a service to create a data snapshot for analysis? For example, the user selects the dataset service; the cloud service provisions the infrastructure and software and copies the snapshot for use; and the user pays for use, decommissioning and releasing the service when complete, and perhaps doing the same thing next month.

3. Consumerization of IT- As an EA, your focus has traditionally centered on what the business needs, and how to support it.  In the past, the “business architecture” was derived from key business stakeholders, and used to create the application, information, security and infrastructure architectures.  Consumerization of IT suggests a revision to that model by making IT responsive to its consumers, users and clients with content and solutions they expect, provisioned as Instant-On . It suggests a commoditization of IT products, and it suggests services offered as a menu of choices. The latter is competitive to that which they can purchase outside IT and which they can provision instantly. It suggests the consideration of the social media strategy. Consumerization of IT also suggests that a number of innovations are required to support these demands.

4. Mobility –Unless you are under a rock, you already see the influence of mobility on your future state architecture, and likely it is already a part of the current state architecture.  This year, however, mobility is no longer a

Enterprise Architecture

bolt-on solution for email and texting in the enterprise.  It is being promoted by the consumer of IT as the preferred device for interactions through “apps.” “Bring your own device” or BYOD is becoming the norm rather than the exception. How will you handle lost devices that have sensitive data on board? [Hint: develop a remote wiping strategy, or limit access]. It’s unwise to ignore your unified communication strategy. Unified Communications as-a-service (UCaaS)* needs to be discussed as a strategy (see this Network World report: top 5 UC predictions for 2012).

5. Context-aware IT – Programmers and designers always consider the parameters of where their products are used, and by whom, but context awareness is a paradigm where new and existing products must be aware of, or capable of understanding, their operation based on the user’s intentions, location, history, tasks or other context-related information.  If I am a plant manager, my interface to technology will change as I use my mobile device in the factory or at home, or if I use my desktop.  As a mobile worker, I would like to enter my timesheet easily while I’m on the road, from a smartphone app, and have full access to reports and detailed data when I’m in the office.  It is deeper than this when one considers the implications for analytics, cloud service selection (the selection asking, “You chose a development platform last time, do you want the same thing now?”) or web-based client interactions.

6. Cloud Computing -  I see an interesting trend where the cloud is disappearing from the hot trends this year. I see this not as an omission, but an acknowledgment that the early adopters have a cloud strategy and have implemented some or part of it.  It is a part of the enterprise architecture more than ever, since the cloud services that are deployed need review for viability, efficiency, and renewal.  If you are operating a hybrid cloud, mixing traditional and cloud services, you have the opportunity to review the mix and put more or less in the cloud. Review your public cloud strategy.  For those organizations not invested in the benefits of cloud computing, you have the opportunity to align your direction to improve the service strategy, process, portfolio, culture and infrastructure to leverage the savings and agility of the Instant-On cloud solutions.

Enterprise Architecture

Reference

http://h30507.www3.hp.com/t5/Transforming-IT-Blog/6-Tech-Trends-That-Enterprise-Architects-Should-Focus-On-in-2012/ba-p/106969

Conduct your enterprise architecture program in six phases

Gartner recommends that chief architects and their teams establish and evolve the EA program using six

major phases. The phases may vary depending on the problems you are trying to solve and the decisions

you are trying to make:

Strategize and plan: Gain agreement on the major problems to be solved; charter the EA program;

and develop a future-state description comprising the requirements, principles and models.

Assess current state: Identify your current level of strategic and EA maturity; gather existing

documents that describe your business and technology capabilities, practices, formal process models,

data and systems.

Assess competencies: Identify budgetary, staffing and other requirements to prepare the business

for the analysis of strategy. Review the established budgeting mechanisms and processes used in the

business and strategic-planning organizations, and consider refining them.

Gain approval: Leveraging the charter from phase one, provide business and IT executives with

Enterprise Architecture

a formal plan, and bring business and IT experts together for a shared strategic-planning exercise.

Develop the requirements, and assess the results.

Implement: Analyze the findings from strategic-planning and EA efforts to prioritize the gaps to be

filled. Develop investment plans using business cases that emerged from EA efforts. Present the

findings to stakeholders and leaders to get investment plans approved.

Operate and evolve: Improve and refine your efforts. Over time, the future state will be articulated in

greater detail.

Applications of Enterprise Architecture

(In social network)

Architecture defined capability to collect ,discover ,represent ,relate, and reason about the knowledge.

it supports dynamic coordination and social use of knowledge resource relevant to missions

Social networking architecture enables evolution of community knowledge

Knowledge is dynamic and evolves with human experience and social networks

An overarching knowledge perspective is required across all architecture views

(In Business)

Enterprise Architecture

The future Development of Enterprise Architecture

Is Enterprise Architecture going anywhere? This looks like a legitimate question. It is, albeit slowly in the absence of an agreed practical framework and clear proof of its business case. The reason is straightforward: EA is a necessary "evil". Any system needs a blueprint enabling proper operation, maintenance, planning... To fulfill the expectations, EA  needs to satisfy its many stakeholders in top management, business, technology/IT and organization.  Here are a few directions, I can see the Enterprise Architecture progressing, in no particular order, but happening in the next five years or so:

A.      EA will finally be recognized as a business discipline, having incorporated Value Chains, Business Models, Strategic Planning...

B.      The EA evolves to increasingly cover business architecture rather than IT alone; the Enterprise Architecture will be the result of the fusion of IT, Business and Organization/People architectures; what is the value of an applications architecture, without the process it implements or the people operating it?

Enterprise Architecture

C.      The governance for EA will be more & more business and top management heavy; this is because it would be used in mapping the strategy to components, to derive the enterprise transformation portfolio, make investments and take strategic and tactical decisions.

D.      The EA development will be increasingly triggered by Mergers & Acquisitions and outsourcing activities; IT BPO, SaaS(ASP) are riding a strong current right now.

E.       The Enterprise Architect would be more and more called in the business decision making process; because the EA architect deals with the business logic, technology operation and strategy, is able to understand both worlds and use both business and IT vocabularies.

F.       A combined EA framework emerges to take advantage of the strengths of various frameworks, such as Zachman, TOGAF, FEA and others.

G.      SOA is recognized as part of the EA program as the target EA style of architecture and technology, rather than executed in isolation as it often happens

H.      EA would be increasingly required by shareholders/owners/investors to provide the blueprint of the business operation to describe assets, provide proof of regulatory compliance, map costs and profits on various operations and align strategy. The US government mandates EA to the public sector. EA would become a regulatory feature for public listed companies.

Benefits of Enterprise Architecture

If Enterprise Architecture is successfully defined, implemented and followed - a simple set of benefits should be delivered - better, faster and cheaper

 

Enterprise Architecture

Organizations  from a wide range of industry sectors who have adopted an architecture approach, report the following business benefits:

A more efficient IT operation

Better return on existing IT investment and reduced risk for future IT investment

Faster, simpler and cheaper procurement

Increased flexibility for business growth and restructuring

Faster time-to-market for new products or even operational innovations

Reduced business risk associated with IT

Bridging of the business strategy & implementation gap

More pertinent and relevant solutions for the business.

Reference

http://www.enterprisearchitects.eu/ea/benefitsofea

Enterprise Architecture

Customer Relationship Management

What Is CRM?

CRM, or Customer Relationship Management, is a company-wide business strategy designed to reduce costs and increase profitability by solidifying customer satisfaction, loyalty, and advocacy. True CRM brings together information from all data sources within an organization (and where appropriate, from outside the organization) to give one, holistic view of each customer in real time. This allows customer facing employees in such areas as sales, customer support, and marketing to make quick yet informed decisions on everything from cross-selling and upselling opportunities to target marketing strategies to competitive positioning tactics.

Customer Relationship Management

Becoming a common and important concept in many industries

Beyond mere ‘Contact Management’

Knowing the customer and the Touch points

Single undertaking view of customers

Most industries have CRM software to help sales process, on-going service, and even accounting

Purposes of CRM

CRM in its broadest sense , means meaning all interactions and business with customer

Improve customer service

A good CRM program will allow a business to acquires customers

Increase value of customer to the company

Retain good customers and determine good customers can be retained.

Enterprise Architecture

Why organization loose their customers:

Product related reasons Competitor reasons Personal reasons Price related reasons Service related reasons

Organization strategies differ on :

An organization strategies towards developing and maintaining sustainable relationship differ from one organization to another

Nature of business Size of market share Nature of product Volume of sale Geographic concentration Socio -economics status Life style of people

Organizations differ in following factors:

People Process Product

Determining the Need for Customer Relationship Program

Is customer retention your primary management objective?

Is customer satisfaction measured and assessed regularly?

Is there a constant effort to enhance customer satisfaction?

Do you measure quality standards and communicate results with your employees?

Do you train and retrain your customer service providers?

Enterprise Architecture

Do you have employee turnover problems?

How much do you spend to keep current customers?

What is your current cost for acquiring a customer?

What is your average annual customer dollar value?

What is your current customer defection rate?

How do you get lost customers back?

Do you constantly deliver what you promise to your customers?

Guidelines for Establishing a Customer-Relationship Program

Examine who your customers are and what specific needs they have.

Identify specific objectives to be realized by the program.

Create a manageable program of customer retention.

Create a culture that stimulates customer interest.

Determine a timetable for evaluation.

What Today’s Customers Expect

Availability: Services designed to meet the customer’s schedule.

Accessibility: When the customer needs to talk, the provider can be reached.

Accountability: Customers prefer quick and accurate answers to service questions.

Enterprise Architecture

General Statistics

The average business never hears from 96% of its unhappy customers,

91% never come back

Those people will tell a minimum of 4 other people,

Getting a repeat customer from this group is 1 in 11,

Dissatisfied customers may tell 9-10 people about their experience,

For every positive they tell 4-5 people,

For every complaint received the average business in fact has 26 customers with the similar concern.

Customer Relationships

Enterprise Architecture

CRM Summary

CRM is the strategic use of information, processes, technology and people to manage the customer’s relationship with a company’s (marketing, sales, services and support) across the entire customer cycle.

The Plan and Practice of managing the lifetime relationship with your customer

CRM focuses on strategic impact rather than operational impact

CRM is a total discipline

CRM includes all functions that directly touch the customer throughout their entire lifetime with a company

Customer Relationships

Enterprise Architecture

.