Systems Consolidation - Is it Business or IT Strategy?

While presenting an architecture blueprint targeting consolidation of few applications, one of the meeting attendee asked couple of interesting questions,

1. Why do we need to consolidate?
2. Isn't Systems consolidation more of an IT strategy than a Business strategy?"

Answer to the first question was easy on the lines that consolidation is required as there are multiple duplicated systems supporting similar business processes. Dupliction is costly, increases complexity, reduce agility, impacts productivity, exposes risk etc.

Answer for the second question was the universal answer, "it depends". It could be business driven or IT driven. Multiple systems supporting same or similar business processes in an organization could be because of different reasons and need to be understood before a system consolidation strategy is considered. Following are few reasons that I observed in my experience,

1. Business Silos: Multiple line of business with similar business processes developed systems in isolation.
2. Time-To-Market: Business grew with a very fast pace and new applications were developed for time-to -market reasons for immediate requirements without considering enhancing existing systems or reusing them.
3. Autonomy: Business required to have repetition for autonomy and flexibility reasons.

It also depends upon other factors like organization core business, strategies, products and distribution channels, geographic locations, business model, current state of the applications landscape etc. In some cases multiple systems might be desirable to support the organization business model.
Systems consolidation strategy could be Business driven or IT driven. In the case of a business driven consolidation, a holistic business services analysis can be performed to identify commonalities in the business services/process across multiple line-of-businesses. This top-down approach allows to consolidate systems supporting similar business services. It also considers the organization long-term goals and strategies. However, this requires upfront buy-in and long-term commitment to implement.

IT driven consolidation strategy on the other hand is usually driven to reduce total cost of ownership (TCO) by reducing the number of systems . It is a bottom-up approach and may focus on moving business logic/data from multiple similar systems to a single system. It may not consider long-term organizational goals/stratgies.

At the end of the day, both strategies work, add value, and help organizations to optimize its resourcess.

Another Modeling Language-ArchiMate

ArchiMate is a modeling language for Enterprise Architecture and recently adopted by the Open Group. I attended a seminar yesterday, "ArchiMate-Adding value to TOGAF" by Remco Blom. Following are few takeaways from this session,

• ArchiMate complements TOGAF ADM in the areas of Business, Information, and Technology
• It’s a higher level modeling language and not a replacement of UML or BPMN.
• It offers a meta model to relate different domains Business, Application, Technology
• It provides visualization for Enterprise Architecture analysis
• There are multiple tool vendors offer support for ArchiMate including , Bizzdesign, Troux, Telelogic,IDSScheer, and Casewise
• The language needs to be enhanced in order to better align with TOGAF
• There are no explicit security view exsit
• Open group announced the launch of the ArchiMate Technical Standard at the upcoming Open Group conference at London.
• The Standard is available in the book form at VanHaren publishers
• Language tutorials are available at http://www.archimate.org/

AOGEA Toronto Chapter event is ended.

This thursday's Open Group AOGEA event went very well with great presentations. It was a wonderful experience to meet so many fascinating people at one place. First half of the session was focused on the challenges Enterprise Architects and Project Managers face due to overlapping interests. My presentation topic was on the "Enterprise Architecture and PMO : Alignment best practices", which was received very well. Second half focused on the recently released TOGAF 9. The presentations powerpoints will be available through the AOGEA-Toronto chapter site shortly.

Quality Assurance is an Architect's job...too.

One of the key responsibility of the Solution Architect is to ensure that quality software gets developed and delivered during the project lifecycle. This demands to be actively engaged in each phase of the project including quality assurance phase. I found following principles handy to ensure effectiveness of the testing cycle from the book "Practical Software Testing: A Process-Oriented Approach " by Ilene Burnstein.

Principle 1. Testing is the process of exercising a software component using a selected set of test cases, with the intent of (i) revealing defects, and (ii) evaluating quality.
Principle 2. When the test objective is to detect defects, then a good test case is one that has a high probability of revealing a yet-undetected defect(s).
Principle 3. Test results should be inspected meticulously.
Principle 4. A test case must contain the expected output or result.
Principle 5. Test cases should be developed for both valid and invalid input conditions.
Principle 6. The probability of the existence of additional defects in a software component is proportional to the number of defects already detected in that component.
Principle 7. Testing should be carried out by a group that is independent of the development group.
Principle 8. Tests must be repeatable and reusable.
Principle 9. Testing should be planned.
Principle 10. Testing activities should be integrated into the software life cycle.
Principle 11. Testing is a creative and challenging task.

Keeping these principles in mind, an Architect can help the testing team in determining the right set of test cases to excercise the components to the fullest and by introducing mechanisms for test automation to improve the testability of the software.

Isn't Business Architect a Senior Business Analyst?

A friend of mine asked me this question while watching Raptors game this week, "Isn't Business Architect a Senior Business Analyst?". Here I am trying to answer this question.

Business Architect role is relatively new as compared to Business Analysts in most of the organizations. The roles have similarities in terms of working with Business and applying similar techniques to understand business needs but there are few differences. While developing Business Architecture capability in an organization it is important to clarify these roles and the difference between them to avoid any confusion . The difference between the roles becomes evident by reviewing the role definitions.

The role definition for a Business Analyst as per the International Institute of Business Analysis is,
" A business analyst works as a liaison among stakeholders in order to elicit, analyze,communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals."

As per The Open Group, the Business Architecture is ,
"The business strategy, governance, organization, and key business processes information, as well as the interaction between these concepts". The Business Architect is the custodian and driver of the Business Architecture.

Other than the salary difference, following are some of the differences in these roles,

Knowledge

• Business Analyst focus is usually a particular business problem in a bigger business domain. Understanding of the business domain is helpful to identify the solution but could be dealt with the help of a Business SME. A complete knowledge of the business goals, strategies is usually not needed.
• A broad knowledge of the business Vision, Strategy and Goals, is a must for a good Business Architect. Business strategy defines the what part of the business goals and the Business Architecture defines how to achieve it.

Role Scope

• Generally a Business Analyst is engaged on a project level scope capturing business requirements and working with the Business stakeholder, Solution Architects, Developers and Project Managers. The requirements are constrained by the project scope, solution provided, and implementation during the project life cycle.
• A Business Architect is engaged at the enterprise level scope defining Business Strategies, Processes, Modeling, Capabilities and Services with Business stakeholders. These activities are planning in nature and are not constrained by the implementation of a particular project.

Following picture depicts the roles in the lifecycle of the project using Nick's "span of responsibility" triangles.

Deliverable

• A Business Architect engages Business subject matter expert, brainstorms, analyze, validate, manage and communicate business requirements . The end product is usually requirements, use cases documents articulating the business requirements and rules.
• A Business Architect works with Business and provide artifacts like Business Strategy, Road maps, Business Processes, Business Process Models, Business Service Descriptions etc.

The conclusion is that although these roles have similarities in terms of working with the Business but the scope is quite different. One BA (Business Analyst) focus is tactical and other BA (Business Architect) focus is strategic. Business Architect role seems to be a natural career progression for a Business Analyst and usually is not the other way around.

AOGEA Toronto Chapter Upcoming Event

AOGEA (Association of Open Group Enterprise Architects) Toronto Chapter is holding its next Enterprise Architecture event on Thursday, Feb 26th. The topic is "Enterprise Architecture Lifecycle: Thought Leadership & Best Practices". Following are the main agenda items,

• Project Managers Challenges
• Enterprise Architects Challenges
• TOGAF 9 and Management Frameworks
• EA and PM Common Vision
• Skills to Execute EALC

I will be presenting on the topic, "EA and PMO: Alignment Practices".

Early registeration can be done by contacting at events_master@aogea-toronto.org.

Biztalk Server 2009 Beta Release

Microsoft BizTalk Server 2009 Beta-1 is released in December and is available for download at https://connect.microsoft.com/site/sitehome.aspx?SiteID=218. It is targeted to be released in the first half of the 2009 year.

The complete roadmap of the product is available at http://www.microsoft.com/biztalk/en/us/roadmap.aspx