Enterprise Architect vs. Service Architect

If you open any book on SOA you find it defined as an architecture which offers a framework for improved business - technology alignment. In [1] SOA is defined as "a framework for integrating business processes and supporting IT infrastructure as secure, standardized components - services - that can be resused and combined to address changing business priorities". The IBM SOA Foundation [2] defines SOA as "the practice of deriving an information system design from a business design".

I find both definitions to be confusing and incomplete. The first definition is basically an enterprise architecture (EA) framework, right? The definition that it is a framework means that it defines governance, perspectives (views) and/or some methodology. Similar to TOGAF, or Zachman (does not have a methodology) or other well known architectural frameworks. TOGAF which is a framework for enabling the design, evaluation and build of the right architecture for an organization [3] offers an enterprise macro level architectural definition. TOGAF defines four main domains - business, data, application and technology. Well, the answer is not quite right. SOA is not EA, SOA is applicable at a level lower than the enterprise, it is focused on the service level, wherever it might be. In some cases services could be enterprise-wide and high level, but most of the time it is local.

Lets think of SOA as the "service instantiated" architecture for an enterprise architecture. To make it easier to understand lets take the example of a small non-profit community center. An enterprise architecture for this community center is the evaluation, definition, design and build of an integrated structure unifying the community center to allow it to achieve its mission. For example an enterprise staff appraisal system as part of that architecture. On the other hand SOA will define how the various services related to a staff performance system can be designed in IT resources and aligned to the business goals. Services could be "Staff Feedback Solicitation", "Performance Appraisal Metrics Definition", "Performance Appraisal Metrics Assessment", and several more. So in a sense SOA is addressing the question of "now we have an enterprise wide structure and method to appraise staff performance, how can we actually turn it on, and customize it for different departments, with optimum reusability of approaches and resources.

Other definitions of SOA is that is it is "a methodology and approach that can be utilized to deliver or to support an enterprise architecture initiative" [4].

______________________________________________________________
[1] Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones and Rawn Shah, " Service-Oriented Architecture (SOA) Compass: Business Value, Planning and Enterprise Roadmap, IBM Press, 2006.

[2] Rob High, Stephen Kinder and Steve Graham, "IBM's SOA Foundation: An Architectural Introduction and Overview", IBM Business Consulting Services, Version 1.0, Nov 2005.

[3] The Open Group, "The Open Group Architectural Framework (TOGAF)", Version 8.1.1, Enterprise Edition, 2007.

[4] Niel Maehiter, Quote in an Article titled, "What's the difference between SOA and enterprise architect?" by Joe McKendrick, June 11th, 2007. (link)

Metrics for Defining the Complexity Level

I was sitting in a meeting when a whole bunch of folks started sharing ideas on how to assess the level of risk associated with a project or system under development (SUD). Some thoughts were to consider the number of requirements, others the number of change requests needed, and some suggested the level of engineering support needed for a requirement to be realized, for example does the requirement call for an architectural change, design change, development change, or just test or only support during testing.

I agree with the last proposal, analyzing the scope of changes is a good way of defining the complexity and hence the risk of the project, then we can create metrics that reflect these different levels of engineering support. Merely looking a total number of requirement, change requests or development teams involved might not provide the most accurate assessment. Instead, the system architecture needs to analyze and study the requirements impact and assess design complications, development challenges, testing validity and deployment issues. This integrated view can provide a more objective feel for the level of complexity involved in the SUD. A system might have only two system level requirements that drive the whole architecture change and hence brings in large design, development, testing, deployment and support efforts, compared to another system which has 2 dozen requirements which marginally impact development and will hence have a much lower effort in other areas and less overall complexity and risk.

I came across some interesting articles and papers on this topic.

A Complexity Assessment Methodology for Programmable Electronic Mining Systems
Software Complexity Measurement
Design Complexity Measurement and Testing
A Function Point Method for Software Complexity Measurement

How do you assess the complexity of a project in your environment?

A System for Complex Event Management

It is expected that about 2 million individuals will visit Washington DC on Jan 20th. This will not be the largest event that draws pedestrian traffic. Each year Saudi Arabia hosts over 3 million pilgrims in Makkah and its surrounding areas for the Hajj worship activities. The Saudi's can attest that is is by no means an easy job, to keep the crowds safe, moving and able to do what needs to be done with ease.

The inauguration is a little different and less complex that Hajj in a sense that the largest part of the event is confined to the Mall and mostly static - i.e. folks are sitting or standing to witness the President as he gives his speech. Whereas, the Hajj is a more dynamic experience. Pilgrims move back and forth between Makkah, and the nearby mountain of Arafat and the valley of Mina on the outskirts of Makkah, 8 km away. Among the pilgrims are also celebrities such as Presidents and leaders of Muslim countries, businessmen, athletes, scholars and other well-known public Muslim figures who have intended to perform their pilgrimage. So the complexities of the inauguration might be much simpler than that of Haj, yet the organizers and teams overlooking its management have put a great deal of effort in organizing it that is worth discussion.

I share a few images - courtesy of the Washington Post - of how the event is organized illustrating security checkpoints, seating areas, entrances, exits, rest areas, vending, etc.. You can call these mission diagrams or context diagrams, at the end of the day the represent the high level architectural overview, which is worth appreciating as it reflects the amount of effort out into managing an event effectively.

The Saudi Government as well has recently taken extra ordinary measures to control the Hajj traffic and ensure safe experiences for the pilgrims. What is interesting is that the Hajj planning never required the closure of any streets in Makkah near or around the Holy Kaaba, unlike the inauguration plan, nor has it required security checkpoints such as those in the inauguration, other than guards at the entrance of the Grand Sacred Mosque for visual inspection.

This is a very interesting domain that is worth research, and I am sure there is a lot to learn from both the Saudi and American experiences.

Update: 3/22/09 - There is a discussion on linkedin related to major event management, you can follow it here, if you are member of "Project Manager Link" group.