Products selection comes after completing SOA design work

Choosing right SOA vendor/products is very challenging and difficult task. Implementing SOA products is not implementing SOA, because you cannot buy SOA. As we all know that SOA is an approach and style of architecture design. Enterprise needs to separate architecture design from the implementation. We need to remember architecture is product agnostic. Productivity, agility, responsiveness, software reuse, and easy to support business growth are among the benefits that an enterprise gains through successful adoption of SOA at enterprise level. Enterprises set its business objectives and technology objectives. SOA helps to achieve the objectives through its service orientation approach. As mentioned above the principles of the service oriented architecture design style or characteristics are modularity, loose coupling, separation of concerns, encapsulation, and single implementation. These characteristics make the IT Environment agile, increase responsiveness, and focused. Therefore, IT environment can sustain change and dynamic nature of today’s business world. The SOA style of design provides several benefits to an enterprise that include both IT and Business community.

Implementation of SOA at enterprise level should be done in small steps. Implementing at single LOB at a time may be easy and less complication. Think about big picture and execute at smallest level.

Primarily SOA should be implemented in an organization adopting an approach that most appropriate for the organization. This can be achieved by creating an Enterprise Architecture framework using TOGAF, FEA, FSAM, and existing EA or any other framework. Creating Governance module upfront can make the process easy. Using COBIT, ITIL, and existing Governance module may be the right approach for most organization to create a new Governance module that support SOA.

Selection of the right software, and hardware should be done after creating a operational module. Selecting products or using existing products are the real challenge in this step. Most vendors try to sell their SOA supported products in very early stage of Architecture Design Cycle. Enterprise needs to go through product selection process carefully and select the right one for their enterprise as specified in the Architecture document. At this step they need to map the products with their physical operational model.

In summary do not select the products before designing the architecture. You design a SOA and then map products to the operational model. If you have any questions please call me.

EAI and CEO Study - an Architect's perspective

Two keywords “Complexity” and “Sustainability” came out from two different 2010 CEO study one by UN Global Compact-Accenture and other one by IBM. CIO/CTO can address these two issues from multiple areas. I think Application Integration is one of the hottest areas which are very complex and most enterprises are spending lot of money and time in business applications support. Cloud computing model can encapsulate the operation complexity, but sustainability and cost containment can only be achieved by addressing the vexing issues. I am exploring EAI in this article.

In most organization applications are running in silos or partially integrated, they are yet to achieve fully integrated systems. Therefore, they are missing numerous opportunities to help their business growth. IT is trying to come out of silo scenario in their IT operation environment for some time through optimization, virtualization, systems integration, etc. programs. Unfortunately even today, most of the IT department facing the challenge of making their IT operating environment simple, and how to support their business to sustain rapid changes and dynamic business environment? This article will give an overview of EAI which is one of the topics of my white papers series that address the pain points of those areas relate to the keywords “Complexity” and “Sustainability”. .

Enterprise Application Integration is a subsystem. It is not a core business function but enable the interaction between multiple business applications that can be one or more integrated business systems, components, external business partners systems, and other business unit systems to provide one or more business systems. EAI architecture defines a framework to:
• Facilitate interaction between endpoints
• Enable distributed operation of business components
• Insulated end points
• Provide an infrastructure that is scalable and extensible
• Explore to use the existing infrastructure services
• Enable reuse of end points
• Enable phased approach to implementation
• Enable easy maintainability

In almost every case, an EAI subsystem will be implemented using packaged integration applications. As a result, product selection plays a central role in the specification of an EAI architecture. This paper focuses on the preparation of the conceptual EAI Component Model. Architecture design should be carried out within the scope of total system development, and with respect to the related EAI techniques.
Prior to initiating product selection the component model need to be elaborated to a specification level. Both product selection and component model specification need to be well documented. The only EAI unique aspect to specification of the component model is the use of the EAI Attributes Blueprint as the consolidated source of parameters for the model.

The EAI Conceptual Architecture should be expressed through a number of work products like Architecture Decision and Architecture Model in the context of enterprise’s EA blueprint, and its Component Model diagram. To develop the EAI architecture five basic steps need to be followed:

1. Make initial architecture decision
2. Identify EAI services
3. Create multiple nodes or partition the systems
4. Identify EAI categories
5. Apply the architecture pattern

In this white paper I have provided an approach to the creation of a conceptual level system component model specific to EAI and other sub products require to implement EAI in a complex IT Environment of an enterprise. Please contact me for the white paper.

The Value of Pattern Analysis in IT Architecture design work.

Christopher Alexander, an architect noted for his theories about design, and for more than 200 building projects around the world. Once he said - “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Of course, he said this about building and towns. But this is true for any design work that includes IT. We see this quote in many IT architecture articles and books. It is true for our everyday life, in music, in creating mold, so on and so forth. In architecture design methodology the value of pattern analysis is tremendous. In designing IT Architecture from scratch or to redesign an existing system the pattern analysis can save tremendous amount of time and money. In service oriented architecture design work we often decompose business process to its coarse grain level to identify a service. When identifying and naming each business process service we are following design pattern concept. Most of the time we do not call it a pattern analysis, but we do pattern analysis. Making pattern analysis as a separate step like use case design modeling or component design modeling, etc., we can get enormous benefit. True value of creating once and use multiple times can be optimized through Pattern Analysis. It gives a structural approach to create right number of services for your architecture design work. Implementing pattern analysis while doing architecture work and how to get maximum value from this work is one of our unique capability. For detail information please contact me.

Virtualization is incomplete if you do not do provisioning, because they are complement to each other.

Workload management, virtualization, and provisioning work together and enterprise can be benefitted by considering provisioning and workload management services at the same time when undertaking a virtualization effort. An architect must include provisioning and workload management services when they are architecting virtualization. Most company focused only on server virtualization as their virtualization endeavor. But the enterprises cannot get the maximum value of optimization through only virtualization, that too only server.
Virtualization improves the utilization of IT resources, information, people assets because it allows you to treat resources as abstract entities, accessing and managing those resources across your organization more efficiently, by effect and need rather than physical location. Virtualization provides ways to abstract physical resources so they can be accessed as a pool of logical resources. Enterprise Architect needs to provision Server, Storage, Network, and Web Services virtualization when undertaking any virtualization effort. Focusing on a single component can be expensive; implementation can be done in various stages but overall architecture design need to be considered taking a holistic view while designing Enterprise Architecture.
As I mentioned earlier virtualization provides ways to abstract physical resources, but if you do not optimize your resources real value of virtualization cannot be realized. Policy-based orchestration is about providing an end-to-end IT service that is dynamically linked to business policies, allowing the ability to adapt to changing business conditions. Having each individual element of an IT system respond to change is a great start, but in the end, to truly be an on demand business requires orchestration of the automation of multiple elements of the systems so that the entire IT infrastructure is responding as it should to changes in business policies or conditions. For example, if a customer’s order entry application suddenly experiences a surge in load, just allocating more CPU may not be enough; it may also need additional storage, more network capacity, and even additional servers and new users to handle the increased activity. All of these changes must be orchestrated so that the dynamic allocation of multiple resource elements occurs seamlessly.

Orchestration enables data centers to move from just-in-case provisioning (providing enough resources to fulfill peaks in IT infrastructure demand, which typically results in low resource utilization) to just-in-time provisioning: automating the infrastructure and executing configuration changes in a repeatable manner, eliminating human execution errors. A typical example of a data center running three applications, in which one application needs additional resources to attend to user demand, while the other two have enough or even extra resources allocated to them. Traditional, manual provisioning practices do not make it practical to move resources from one application to another to meet short-term peaks in demand. Instead, we engage in what we call the just-in-case provisioning cycle: If you look carefully, virtualization and provisioning are complement to each other.

Benefit of virtualization and provisioning flows ultimately to Workload Manager. workload Manager and system provisioning work together. System Provisioning monitors workload across a set of provisioned devices. Enterprise Workload Management (eWLM) is one example of a monitoring technology that provides a basic infrastructure for monitoring and managing a collection of heterogeneous distributed servers.
Workload Management refers to any subsystem that provides functionality to distribute workload across resources within a system or across systems within a network. Within a system, these are usually provided by operating system services, and manage processor, I/O and memory resources according to task priority, resources requested, available resources and other scheduling rules. Higher level OS facilities (e.g. LPARs, Process Resource Managers) may also be available to limit and/or dedicate specific resources to specific tasks or task environments.

A successful EA design should encompasses Workload Management, Provisioning and Virtualization.

Business Resiliency in today's IT World

Business resilience has moved us from the sense of reacting and then recovering from an event to becoming impervious to the event. Business continuity focus upon a defensive resilience posture, it consist of three components – Recovery, Hardening and Redundancy – these are widely recognized as vital ingredient for successful business continuity plans. A defensive posture is useful in protecting the organization and its revenue streams but it does not directly help the bottom line.
An offensive resilience posture also consists of three components, which are focused upon improving the organization’s competitive position – Accessibility, Diversification and Autonomic computing. In practice these components can be used all together or in various combinations depending upon need. For example diversifying operations might allow hardening to be limited other than at sites where critical applications and data reside.
Business resilience encompass business as well as IT Operations and it can be thought of as spanning six discrete layers: Strategy, Organization, Process, data/application, technology and facilities/security. Please contact me for more information.

Right delivery channel strategy that includes HW/Devices, SW, Architecture, and Technology can help to reduce enterprise IT cost.

Software license fees are going up every year, managing assets is also getting expensive. Most enterprises are not looking into their cost of delivery channel. I would like to focus here on delivery channel. For large enterprises, this is a substantial cost and need attention. Enterprises need to have a right client strategy to optimize and control cost. Client is a part of the delivery channel of an Enterprise Architecture. It encompasses, the Software, the Hardware and the delivery devices like desktop to notepad, PDAs, smart phone, near field communication devices, and many other hand held devices that are used to support end users day to day work. Creating enterprise client strategy needs major work and it is time consuming, as we are having so many options. We have so many software, and hardware to be selected from substantially large array of products and also from multiple vendors like Google, Microsoft, IBM Lotus, and open source products just a name a few. We need to create a client strategy, as well as road map that will support immediate need of the enterprise, as well as be able to accommodate future need. Enterprises need to serve multiple channels/users. Policy and governance model for each channel are different. Today’s enterprises typically support Business to Business, Business to Customers, Business to Employees, and Business to Agents channels. Selection of right platform with right software need to be designed based on use case definition for each channel along with the other modules that an EA design needs. Finding out the pattern and common functions for each LOB is very critical. Implementing collaboration functionality among and within the channels is becoming challenging, as one has to select right products set. Carefully architecting and developing right strategy will help to keep the cost down (License fees, TCO, asset management, etc.). I see this as a major architecture endeavor for any organization. Initial investment can help cost savings in down the road. Implementation of control and policy may be a nightmare. Right strategy, right policy will definitely reduce cost, will increase productivity, and boost innovation. Now the question is how to determine what amount of budget need to be allocated for this initiative?

IT Strategy and Roadmap

Enterprise IT covers a large area therefore to develop an IT Strategy one can take a holistic view or a specific component or number of components at a time. Whatever one’s approach may be one need to address all the components of an enterprise IT Environment at some point. In this article I will try to explore the IT Strategy development and the focus will be on an enterprise IT environment. According to Merriam Webster’s dictionary a strategy is an adaptation or complex of adaptations that serves or appears to serve an important function in achieving evolutionary success. A careful plan or method. Therefore, Information Technology Strategy or IT Strategy should have some target or goal that one or an enterprise try to achieve. Therefore, we need to establish an achievable goal or goals carefully. It makes more complicated when we add dynamic nature of today’s information technology. To make it simple, let’s eliminate dynamic factor of the information technology and establish goal(s) using current technology which support agility. Please contact me for detail information.