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