Enterprise Architecture, IT Strategy & Others » Enterprise Architecture

IDentity Managment Strategy

prabasiva — Thu, 07 Jan 2010 06:11:05 +0000

Before we seek Identify Management solution for an organization, the organization must define its business strategy in context to IDM. There are organization which requires to have multiple credential to login to multiple system in the landscape. Most of the federal government organization believes that the system landscape is much more secure when each system in the landscape has its own authentication scheme. To amplify that point, each user of the system in the landscape will have 5-6 credentials. One login credential for desktop, one for email, one for using internet, one for using the systems, one for using HR systems and etc. The idea behind this is, if a system security is compromised then it will not impact other system. At the same time, each users are asked to remember 5-6 user name and password. Users tend to forget the user name/password and require more help desk personnel which increases over all support cost.

On the other hand, when organization require to provide ease of use for its systems in landscape, it moves towards single sign on (SSO) and security architecture principle is one user, one identification. The risk with this approach is, if a system is compromised, the entire systems in the landscape will be compromised.

For each scenario, there is entirely a different identity management solution. IDM includes

User provisioning
User management
- Role Management
- Audit Control
Access Management
- Authentication
- Authorization
Directory services
Work flow
Federation
User de-provisioning

The components of IDM aligns to the process steps I laid out for IDM few months ago.

Identity Management solution can be simplified when the existing and must have directory service is extended to use for other areas. That is, when an organization uses active directory services as a authentication scheme for a desktop/laptop/pc and there is no plan to change it, the recommendation is to study how the active directory service can be made available for other areas like authentication of web application, email and etc.

Take aways:

Must define the identify management direction based on business strategy (in the context of IDM)
Leverage existing and must have directory service
Select a product (for instance Sun Identity Management) which integrates with directory service, user management, and open standards for work flow , provisioning and de-provisioning
Based on IDM direction, synchronize the credentials (like email, desktop login, unix server login, mainframe login, HR system login, benefits system login)
Manage user entry and exit process in a cohesive manner and automate the creation and deletion of credentials in all areas.

Note: This page is used for google’s page rank emprical analysis. The links will be created based on the random graph created. This is node #5 which has the key word: xysivabodzinyx , xysivabodzinxy

Posted in Enterprise Architecture Tagged: Identity Management, Security, Security Architecture

An Evaluation Matrix for an Enterprise Architect

prabasiva — Fri, 06 Mar 2009 10:51:21 +0000

Some times, a simple concept may be crystal clear to you in your mind, but, it may be difficult to grasp by the audience. Enterprise Architects must continuously work on the soft skills to communicate a message successfully irrespective of the audience knowledge level. In that regard, an evaluation matrix for an enterprise architect is given below.

Perform the necessary action to meet the given objective and unable to communicate to the necessary stakeholders = FAILED, as an enterprise architect to meet the mission
Does not perform the necessary action to meet the given objective & unable to communicate to the necessary stakeholders = FAILED, as an enterprise architect to meet the mission
Does not perform the necessary action to meet the given objective = FAILED, as an enterprise architect to meet the mission
Perform the necessary action to meet the given objective and able to communicate to the necessary stakeholders = SUCCESSFUL, as an enterprise architect to meet the mission

A set of soft skill must be possessed by an enterprise architect to be a successful enterprise architect. Enterprise architect must be able to connect to the application team, infrastructure team, IT finance team, IT procurement team, business teams, senior management, executive management and others.

Posted in Architect, Enterprise Architecture Tagged: Architecture, Enteprise Architect, Enterprise Architecture, IT Architect, IT Architecture, IT Strategy, Strategy

How EA can assist in the global economical crisis?

prabasiva — Thu, 30 Oct 2008 22:58:50 +0000

Economist and financial analyst says the current economical condition is the worst since great depression. The crisis exist in all fronts. The magnitude of global issues are very high. The financial & economical growth are not bright in near future. Companies are looking for cost optimization and eliminating discretionary spending in all areas.

Enterprise architects can play a signficant role in any organization to optimize the current spend and provide facts based data to eliminate the discretionary spending. Enterprise architects are the best qualified and well suited person to perform this role since they understand holistic view of organization from financial, organization, application, business, information and infrastructure perspective.

Potential cost optimization areas where enterprise architects can assist an organization

Contract negogiation with existing providers (software, hardware, maintenace and enhancement, right sourcing, contractor, professional services)
Application portfolio assessment – Sundown or eliminate applications in the landscape does not add signficant value to core business processes
Technology simplification – Eliminate and reduce the technologies in the landscape
Sourcing strategy – Bundle the applciation for cost effective service offering
Reduce technological complexity – Migrate the enterprise software (like IBM websphere or BEA weblogic, IBM DB2, Oracle, Portal server and etc)usage to open source software
Maximize Web 2.0 technology for corporate colloboration- (Use Wiki, Blogs, youtube and etc)
Assist business teams in optimizing the business processes – reduce steps in return reduce head counts
Explore to migrate current licensing models to the term based licenses to improve the cash flow of organization

Posted in Enterprise Architecture Tagged: Architects, CEO, CIO, Enterprise Architect, Enterprise Architecture, IT Landscape, IT organization, IT Strategy, ITM, Strategy

Enterprise Architecture – Team Size Analysis

prabasiva — Sat, 18 Oct 2008 15:30:04 +0000

I believe there has been increased clarity on the information architecture roles in the recent years. Particularly there are few good healthy discussions on how to develop an enterprise architects and what should be their roles? and what is the value proposition to an organization? In general, there is a better awareness in the senior and executive management teams to differentiate an enterprise architect with other architects (system architects, information architects, business architects, process architects and etc). It has been a challenge for the executives to define the apt size of the enterprise architects for their organization.

The question is: What is the apt size of an enterprise architecture team for an organization?

Consultant Answer: It depends..

Consultant answer is correct.

The real question is: What are the factors used to determine size of an enterprise architecture team in an organization?

The list of enterprise level factors used to determine the size of an enterprise architecture team.

Number of products/service provided by the organization
Revenue of the organization
Profit of the organization
Business Process maturity of the organization
Finance & controlling maturity level

The list of IT factors used to determine the size of an enterprise architecture team.

Number of people (including employees, contractors, consultants, out sourced) and their ratio
IT budget and Finance management controls
IT Process and system maturity level
Enterprise architecture adaption rate (or EA maturity assessment)

Based on the above factors the EA team can be classified as large, medium and small. Large is of team size of 50+, medium is of team size between 15-50 and small is of team size less than 20. Let me emphasis the small EA team. I believe majority of the corporation will come under this category and let me expand on the small size of EA team.

Organization structure for a small size EA Team:

Chief Architect (or manager of EA team) should directly report to the CIO. Along with EA function, IT Finance management, IT Security, SOX controls, vendor management functionalities also should come under the same small size EA team.

(Double click the image to zoom..)

Posted in Architect, CIO, Enterprise Architecture, IT Landscape, IT Strategy, Strategy Tagged: Architect, CIO, Enterprise Architect, Enterprise Architecture, IT Financial Management, IT Strategy

Patterns in software engineering – An Introduction

prabasiva — Wed, 17 Sep 2008 02:30:15 +0000

What is a pattern? (in software engineering world)

A predefined solution for a problem for the given context.

Key words in the above definition is problem, solution and the context.

What are the different categories of the patterns ? (in software engineering)

Analysis patterns
Design patterns
Architectural patterns
Technology patterns
Integration patterns

Why do we use the patterns?

Objective of patterns is to enhance

Reusabililty
Repeatability

in return will fetch

Cost efficiency
Agility (time to market)

Where the pattern concepts started in general ?

The pattern concept has been in use for thousands of years. In the building architecture and design, we have been using the patterns quite extensively. Ancient buildings like pyramids, roman collegium and lot more used the patterns in the implementation. For instance, the pillars used in ancient temples built in Thailand, India and etc are patterns. They did not design the pillars every time. The pillars are to hold the load of the building. We can notice the reusability and repeatability of the pillars in multiple places in those ancient building architecture which in returned improved the ancients to be effective and quick.

What are the types of patterns in each category?

There are conceptual, logical and physical patterns in each category. Conceptual patterns are very high level solution for the given problem at the given context. Physical patterns spells out the implementation solution for the given problem at the given context. Logical patterns are between physical and conceptual.

Different types of architects

prabasiva — Thu, 21 Aug 2008 03:55:04 +0000

Architect defines the architecture. Broadly the architects are divided into the technical and business architects. The business architect are focused on the economical change of the market and devise a set of business process for enterprise or systems adaption and to attain enterprise or system’s mission and vision. The technical architects are focused on implementation of the business architecture defined to meet enterprise’s or system’s mission and vision.

The technical architects are broadly divided into

Based on the architect characteristics, the types of technical architects shall be divided into the generalist and specialist. The specialist focus on one specific area and the knowledge acquired and possessed by the architect is deep. Where as the generalist, knowledge acquired and possessed in a set of areas is broad.
System/product Architect

System/Product architect are the generalist, responsible for the cohesive architecture solution of the system or product. They have equal strength in the both technical and business area. Plays a vital role to bring all the stake holders together and ensure all the stake holders concern’s are captured methodologically, formally documented and validated. Assist the project manager to make the management decision and makes key technical decision for the project/system/product. Brings all the technical architects, development teams, system analyst, and support teams together to ensure the cohesive architecture is defined to meet the stake holders concern and ensures the defined architecture is implemented. The system architecture validation is done by using the user case scenarios. +1 view of the architecture. The architecture verification is done through reviews.

Domain Architect

Domain architects are the specialist, responsible for the architecture solution for that domain. The domain architect is an abstract definition and there are various domain architects. The domain architects specific to the web development projects are

Application architect
Data architect
Information architect
Integration architect
Security architect
IT Process architect
Infrastructure architect
- Network architect
- Server architect
- Web run time architect

Solution Architect

Solution architecture team is the set of specialist working together to research and seek solutions for a specific problem.

Applied Architect

Applied architects are match makers. The applied architects have the known set of problems, solution and context. The architectural patterns are applied to the system or product. The architectural patterns includes to the process solution or methodology for the implementation and its style.

Enterprise Architect

Enterprise architect are responsible for defining the holistic architecture solution for the entire enterprise.

How to become an enterprise architect ?

prabasiva — Tue, 19 Aug 2008 03:20:52 +0000

For past few years, quite a few employees, contractors, consultants, right sourcing consultants in the organization asked me this question, what they should do to work for me? In other words, how they could become an enterprise architect. Generally, when someone has this question in the organization, I asked them to schedule a mentoring meeting and try to understand what they want to do and how their aspiration and ambition fits into an enterprise architect’s requirement and coach them accordingly. When this questions became a frequently asked question to me, I decided to document the state transition diagram for an enterprise architect and started providing it to whom ever wants to become an enterprise architect.

I believe this has a value to anyone who wants to become an enterprise architect. This state transition is an ideal road map to become an enterprise architect. When I attended a Gartner conference recently, I informally bounced this idea with fellow enterprise architecture managers, chief architects, chief strategist and most of them agreed that this is the ideal road map for developing enterprise architect talent in an organization.

EA – Make an impact and enjoy

prabasiva — Mon, 04 Aug 2008 04:11:45 +0000

Enterprise Architecture is all about making an impact to the organization in various perspectives like technical, financial, business, organization, information, infrastructure and etc. Making an impact to organization will not happen if some one just does his/her job. EA must enjoy and love their job to make an impact to the organization. The love and joy should not be synthesized but naturally initiated and developed.

The real meaning of success is making an impact and enjoy what you do every day – Dr. Ralph Shrader , Chairman & CEO of Booz | Allen | Hamilton. This concept applies to all the jobs in general. The Enterprise architects in the IT organization are the roles have very high likelihood of making an impact to the IT organization. If you want to be a successful Enterprise Architect and make an impact to the organization, understand the EA, navigate the organization, add value to stakeholders and ENJOY doing it every day.

Delphi Technique – A must have for an Enterprise Architect

prabasiva — Mon, 04 Aug 2008 02:38:41 +0000

Enterprise architect provides a service to internal customers (who are also fellow employees of the same organization). The value of the enterprise architects are demonstrated to the organization by providing value added consultation and services to the projects team, senior management team and office of CIO. For instance, enterprise architects shall create a technology road map, the future technologies must be used by the organization for any future projects. The project team who wants to follow the road map may not have enough technological exposure to take steps to implement the component of the technology road map in their projects. There may be many reasons not to follow the technology road map by the project teams. The reasons could be political, technical, operational, irrational, and etc. Most frequently the reasons would be presented as rational but the real core reason could be irrational. Until the EA really understands the motive of not following the technology road map, the EA is not going to be successful in the organization. It is a must for a successful enterprise architect to understand the real motive. Why the road maps are not followed? There could be a real issue in following the road map. For instance, if the technology road map indicates to use BPMS for all future projects. The project who understand the technology road map wants to use this technology in their project, but the vendor may be very inflexible in their license, or it could be expensive, there could be resource constraints in the job market and etc. The EA who walk away after creating the road map will not face the problems but their recommendation will not be followed in the organization for legitimate reasons.

Sometimes the reasons would not be legitimate reasons. The project teams do not want take risk by adapting new technology to their project. Could be due to, cost of the resources in the technology, creditability of the EA team, unknown reasons.

It is non technical problem and it is more organizational political problem. There is no logic directly required to solve this kind of problem. When no logic is followed on purpose, then it becomes logical. This topic deserves a separate blog posting. (Topic: ” No logic on purpose is also logical”)

In this case, Delphi technique is one of the best technique to understand why EA recommendation is not accepted and followed. By engaging on the informal discussion with the various stakeholders in the organization and correlating it would provide the insight on the real motive of the key stakeholders for not following the technology road maps.

The technology road map is an example. There are many areas this technique would be followed by EA and IT strategist. There are numerous area where the similar problem exist, delphi technique is a best way to go around and get into the crux of the problem. EA should be mastered in this technique to be the best EA and provide the greater value to their internal customers.

Key deliverables of IT Strategy – High level overview

prabasiva — Sat, 26 Jul 2008 03:12:28 +0000

In an executive summary, the top 5 key deliverable of IT Strategy team:

Formation of IT Strategy – In collaboration with senior executive management team, create the IT organization vision, mission,strategy map (representation of strategy),alignment with corporate strategy and other functional strategy like sales & marketing, accounting and etc
In collaboration with the senior executive management team, create the organization goal (or strategic theme/focus for the given year), theme owners (senior leadership), set of performance measures for each theme, targets for each measures,
Balanced Scorecard – Set of initiatives, initiative managers, their plan towards the initiative. (Balanced scorecard can be managed using software as a service solution from vendors like Palladium. It is very cost effective approach instead of having few resources in the PMO team tracking the status of the initiatives for the entire organization )
Strategy focused organization – Aligning the IT organization to the IT strategy. Ensure the employee goals are aligned to the IT Strategy. Ensure the structure of the organization supports the IT strategy. It is also called sourcing strategy.
Strategy communication – Continuous communication of the IT strategy and progress being made by the organization towards the IT strategy to business teams & IT teams. Via bulletin boards, brown bag session, departmental town halls, organization town halls