IT Landscape

Twitter in enterprise

In last few weeks, there has been increased attention to Twitter micro blogging concept and technology since president elect Barack Obama’s twitter account was hacked along with few other celeberties.  Micro blogging was a dismissed concept in its infancy stage and due to its adaption particularly by the teens  it gained its popularity and benefit visualization was accomplished in a short time span.

Micro blogging is a compontent of web 2.0 and web 2.0 has been seriously considered by enterprises to maximize the benefits.  Vivek Kundra was promoting Twitter in the public office and there are major benefits of micro blogging in the emergency operation.

My views on how Twitter can be applied to an enterprise.

  1. Twitter can be used to communicate the status of various team members tasks in Agile software development methodology.
  2. Twitter can be used to keep the key stakeholder updated on the recent progress in production outages resolution (part of incident management)
  3. Twitter can be used to keep the team members up to date on execution of a major projects when teams are spread across the states, countries and continents
  4. Twitter can be used to understand what employees really LOVE to do. (All HR policies must be applied before enterprise uses this information for its use)

How EA can assist in the global economical crisis?

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

Patterns in software engineering – An Introduction

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.

Application Portfolio Assessment – Key metrics and its measurement technique

Quality attributes of a system are few key metrics used to perform the application portfolio assessment. Quality attributes like maturity, adaptability, flexibility, availability, stability are quite a few frequently used metrics in the application portfolio assessment. All of them are subjective metrics and can not be measured directly. All of these metrics are measured through various other observed parameters. Among the listed quality attributes maturity and stability are predominately used in the assessment.

Let me propose how the maturity and stability of the systems can be measured in the landscape to perform the assessment. The purpose of the application portfolio assessment is to rank the system in various categories (same as the Boston consulting methodology). In simpler words, the list of applications which are cash cows to the company, list of applications which are dogs, list of applications which are stars and “?” question mark.

The idea is, as an enterprise architect and IT strategist, you want to make sure all the cash cow applications are stable, matured and in general, has very low risk. Measuring the stability and maturity are very subjective and often it is difficult to present the realistic picture in the exercise.

Stability represents the availability of the system. If a system is stable means that it is running in a solid platform provides a better high availability. The availability of the system can be measured by collecting the number of outages occurred, number of preventive measures (emergency change controls), number of special care taken (like special jobs, running jobs manually which are planned to run as per the schedule), number of upgrades and technology architecture. All these factors come together to derive the probability of the system failure in a given time. The probability translates to the stability of the system. If the probability of failure is negligible, then the system is very stable and if the probability of failure is very high and then the system is very unstable.

Maturity represents the obsolescences of the system. Technology and functional obsolescences are two parameters represents how much of the functionality of the systems are continued to be used by the end users, and how technology obsolescences presents the number of legacy technologies being used in the system. If the technologies used in the systems are kept up to date and fully supported by the software providers, then the technology obsolescence is considered very low. The functional obsolescence can be calculated by counting the number of functional points in the system and total number of functional points that are being used. More the number of functional points not being used by the end user the more the functional obsolescence is. More functional obsolescence is less the system maturity is.

Stability and maturity of the system can be used by the above proposed approach.

When and how to use BPMS?

Business Process Management Suite (BPMS) is a set of tools truly enables the following key strategic objectives

  • Business – IT alignment
  • Time to market (Agile software development)
  • Adaptability
  • Process Efficiency – Foundation for Six Sigma
  • and lot more

If BPMS is in the technology road map and the organization is following the road map to move towards the vision, BPMS must be articulated to the executive management teams both in IT and business. The executive management teams may ask high level questions to understand how the BPMS fit in the organization landscape and how it will assist the organization to move towards the vision. When you deal with executive management team before you make them understand some concepts, ensure you erase the misconception they might already have. What BPMS can not do?

BPMS is going to replace all ERP like SAP, PeopleSoft?

BPMS will not replace the existing ERPs, portfolio systems. BPMS will stay top of it and orchestrate any new system development involving all key enterprise systems like ERP, portfolio

BPMS can be used for technology migration projects? Example, From database version 1 to version 2?

BPMS purpose is not to use technology migration project. First of all, BPMS can not add any value in the technology migration projects.

Few frequently asked question by the executive management team related to BPMS direction are listed below.

When to use it?

Use for a new system development if – the business processes changes frequently and they are core business processes, services provided by the new system can be used across different products, the requirements of the systems are relatively vague and would change frequently, involves multiple teams to complete the life cycle of the system function.

How to use it?

From get go, approach the BPMS will be used by both business and IT teams. Get the business teams involved from the beginning, engage them in the initial market research, selection & evaluation and financial commitments in procuring, establishing the foundation like infrastructure, competency centers. Bottom line, it should not be perceived as IT tool. It is a tool used by both business and IT team. How to use it? Capture all the business process flow, analyze the business processes, implement and manage it. All done in the same tool.

How the teams from IT and business work together? (particularly how the IT architects and business process designer work together)

The tool, methodology and approach brings both the IT and business teams (IT – Business alignment, partnership) together by design. The business team will be using the tool to document the business processes (for any project requirement), business analyst/consultants from both IT & business will analyze the business requirements using the tool (like simulation, identification of bottle necks etc), IT architects will build the connectors (to the ERP, Portfolio, enterprise database ware house), IT architects/consultants will auto build (code generation) the application using the tool, business analyst will using the same tool to perform business activity monitoring (let us say, the requirement is to build the credit decision engine and BAM will used to monitor the approval rate by state, product, type of loans etc)

What are the core competencies the IT organization must have to move in this direction?

Business consulting to business, innovation, business process management, business process modeling, business architecture, enterprise architecture, strategy, IT finance management, SLA management, vendor management, etc

How the development partners (like out sourcing partners) play a role in this setup?

Like any software system, the quality of the software systems are not guaranteed until verified/tested. Out sourcing partners can a play major role in verification (testing) of the newly build software system. They can play a role in building the connectors in BPMS. They can play a major role in maintaining the enterprise systems like SAP, PeopleSoft, CRM, etc They can play a role in assisting in capturing the business processes in the tool (the percentage should be very low in this category)

How different architects work together to define software system architecture?

The involvement of various architects in the system architecture definition process is given in the responsibility assignment matrix (RAM) in the table 1. All the architects work together to define the software system architect.

Table 1. RAM for architects.

Architect IV FV CV Dev.V DV OV
SA C C C AC C C
AA I A I I I I
DA A I I P P P
IA I I I P P P
INA I I A P I I
SECA P P A P P P
PA NA NA NA I I I
NA P P P P A A
SEA P P P P A A
WRA P P P P A A

Table 2

Code Description Comments
A Accountable Responsible for success/failure of this activity
P Participant Actively participates in the activity
NA Not applicable This person is not applicable for this task.
I Input Provider Project Team needs input from this person in this activity
S Sign-off Required Must sign-off the appropriate document
C Co-ordination Co-ordinates and Leads the effort.

Table 3

SA System Architect
AA Application Architect
DA Data Architect
IA Information Architect
INA Integration Architect
SECA Security Architect
PA Process Architect
NA Network Architect
SEA Server Architect
WRA Web Runtime Architect

Table 4

IV Information Viewpoint
FV Functional Viewpoint
CV Concurrency Viewpoint
Dev.V Development Viewpoint
DV Deployment Viewpoint
OV Operational Viewpoint

What is software system architecture?

Software system architecture is collection of viewpoints. The types of viewpoints depends on the type of systems. Software system architecture for a typical web application contains information and functional views primarily focuses on the structural (or static) representation of the system and the deployment, concurrency and operational views are the behavioral (or run-time/dynamic) representation of the system and the development view is guidelines. Views are instance of viewpoints. Viewpoint is a set of standards, guidelines, templates, patterns for constructing a view.

Functional viewpoint:
The functional viewpoint represents the business processes and function elements of the system. It is mandatory for all web development projects since all web projects are executed to meet a set of functional requirement.
Information viewpoint:
It represents the data and flow of the data within the system. The data or information is integral of the web system.
Deployment viewpoint:
The typical web environment contains minimum a web server with internal disk, domain name server, web browser, inter network or intra network. The environment could be complex for a transaction application. It contains quite few infrastructure components like web server, router, switches, firewall, application server, domain name server, intrusion detection devices, messaging services, storage management systems, load balancer, ssl accelerator, external cache devices etc. It is essential to understand the deployment view of the system upfront during the architecture definition phase of the software development life cycle.
Development viewpoint
In an enterprise environment, there are set of standards, policies, patterns, anti-patterns, reference models, lessons learned, domain knowledge, reference architecture and etc. The development team is expected to reuse the existing references. These artifacts are provided to the application developed team by the centralized architecture team. With recent success of the outsourcing development model, the development viewpoint is required to be part of the architecture.
Concurrency viewpoint:
The functional elements of the system are to be served simultaneously for concurrent users in the web environment. It is required to study the behavior of the concurrency structure of functional elements. It enables to create the necessary environment setup like thread configuration for the operational viewpoint.
Operation viewpoint
The gap between the application development process and the infrastructure management process is quite significant in the industry in spite of the well known IT infrastructure management frameworks like ITIL being in place and adapted widely. The longevity, sustainability, maintainability of the system are determined how the operation views are analyzed and designed during the architecture phase of the project. It may be optional if the web application is developed for a limited time.