open-group – Page 2

Heather Kreger, IBM, on SOA standards

It’s impossible for me to pass up a standards discussion (how sad is that?), so I switched from the business analysis stream to the SOA stream for Heather Kreger’s discussion of SOA standards at an architectural level. OASIS, the Open Group and OMG got together to talk about some of the overlapping standards impacting this: they branded the process as “SOA harmonization” and even wrote a paper about it, Navigating the SOA Open Standards Landscape Around Architecture (direct PDF link).

As Kreger points out, there are differences between the different groups’ standards, but they’re not fatal. For example, both the Open Group and OASIS have SOA reference architectures; the Open Group one is more about implementation, but there’s nothing that’s completely contradictory about them. Similarly, there are SOA governance standards from both the Open Group and OASIS

They created a continuum of reference architectures, from the most abstract conceptual SOA reference architectures through generic reference architectures to SOA solution architectures.

The biggest difference in the standards is that of viewpoint: the standards are written based on what the author organizations are trying to do with them, but contain a lot of common concepts. For example, the Open Group tends to focus on how you build something within your own organization, whereas OASIS looks more at cross-organization orchestration. In some cases, specifications can be complementary (not complimentary as stated in the presentation 🙂 ), as we see with SoaML being used with any of the reference architectures.

Good summary, and I’ll take time to review the paper later.

Ron Tolido, Capgemini, on (or not on) open BA methodology #ogtoronto

Ron Tolido of Capgemini presented on the case for an open methodology for business analysis. There’s a big component of standardization here, particularly a shared language (terminology, not necessarily natural language) to enable collaboration. He considers the core competencies of business analysis to be information analysis, subject matter expertise and business process management, there’s also an aspect of consultancy around managing change.

In spite of his categorization of BPM as an “IT tool”, he highlighted the importance of process in business analysis today, and how process orchestration (although he didn’t call it that) and business rules can create applications much faster than before. This allows business rules to be changed on the fly in order to tune the business processes, and the creation of configurable user experiences by non-IT people.

Echoing the confusion of the previous presentation on the IIBA, Tolido stated that business architecture and business analysis are different, although business analysts might be involved in business architecture work without being business architects themselves. It appears that he’s making the distinction of business analysts as project-specific resources, and business architects as enterprise resources, although it’s not clear what functions or capabilities are different. There was a lot of audience interest in this issue; there appears to be the will to combine the disciplines in some way, but it’s just not there yet. I’m not sure that there’s sufficient common understanding of the term “architecture” as it pertains to non-technical disciplines.

Kathleen Barret, IIBA, on the Business Analyst role #ogtoronto

Kathleen Barret of the International Institute of Business Analysis discussed how the role of Business Analyst moved from assistant Project Manager and scribe to the focal point for understanding and articulating the business need for a solution or change.

She started by talking about why there is such a strong case now for business analysts. Organizations have been designing solutions for years without proper business analysis, resulting in a spotty success rate; in today’s economy, however, no one can afford the misses any more, prompting the drive towards having solid business analysis built in to any project. There’s also a much stronger focus now on business rather than technology in most organizations, with business strategy driving the big projects.

IIBA was created 5 years ago to help support business analysis practices and create standards for practice and certification. Its goals are to develop awareness and recognition of the BA role, and to develop the BA Body of Knowledge (BABOK) to support BAs.

Business analysis is about understanding the organization: why it exists, its goals and objectives, how it accomplishes those objectives, how it works, and how it needs to change to meet its objectives and future needs. As Barret points out, there’s a big overlap with what business architects do (she posits that they are now the same, or that an enterprise business analyst is the same as a business architect – I’m not sure that IIBA has a well-thought-out position on this yet); the difference may be purely a matter of scope, or of general analysis versus project-specific analysis.

The BA works as a liaison amongst stakeholders in order to elicit, analyze, communicate and validate requirements for changes to processes, policies and systems. This could be at the enterprise level – probably what most of us would refer to as a business architect – or at the project level. This can be a subject matter expert or domain practitioner (which I don’t consider a true BA in many cases) or a consultative BA who works with SMEs to elicit business requirements. In a large, complex organization, there may be several types of BAs: there is a need for both specialists (in terms of business vertical, methodologies and technologies) and generalists.

IIBA will continue to extend the BABOK, and will be releasing a competency model by the end of 2009 to help BAs identify gaps in their capabilities and to help organization to assess current needs and capabilities. In my experience, “business analyst” is one of the most over-used and misused term in business today, so anything that IIBA does to help clarify the role and expected capabilities has to help the situation.

David Foote on EA careers #ogtoronto

Foote presented some interesting – but for this primarily Canadian audience, not completely relevant – statistics on US unemployment; he added the comment “I assume it’s the same in Canada”. Would have been good if he had actually taken 5 minutes to research our job market before presenting here, because there are some significant differences, although many similarities. He followed this with the rather obvious observation that there is always a shortage of talented people with specific skills, and that in an economic downturn, companies are looking to hire quality rather than quantity.

He brought forward recent Gartner research that showed that more than half of EA programs will be stopped in 2009, and that the remaining ones will embrace cloud computing but will struggle with framework and information management problems. Foote pooh-poohed this, and said that there were only a handful of good analysts out there, and that this was not based in fact. The implication is, of course, that he’s one of those good analysts. 🙂

There’s some pretty interesting numbers about pay scales for architects in his research, which was gathered from cities across the US and Canada: although there are a lot of people out of work and salaries are going down, architects with certain certifications are holding steady or even increasing their worth. Whereas the value (presumably measured by pay) of web developers has dropped by over 28% in the past 12 months, architects and project managers – which were, inexplicably, combined – increased by over 4%. Topping the list are Check Point Certified Master Architects and Microsoft Certified Architects, each of which increased in value by 20% in the past 12 months. There are some non-certified skills gaining in value, too: I’m not at all surprised to see process leading the pack at 8.3% increase, since an economic downturn favors process improvement projects.

He showed us some detailed stats on pay scales for architects across a range of US and Canadian cities, and summarized for each country: enterprise architects, data architects, information architects, senior applications architects, applications architects, security architect and director of architecture. He presents these (and therefore architecture in general) as purely IT roles: this is all in the context of IT pay scales, and contains nothing on business architects.

The presentation finished with some of the barriers to enterprise architecture:

Many EAs live in a siloed world, funded by business silo, and are expected to bridge silos with “nickel and dime” funding
There is a disconnect between IT leadership and EA governance, with many CIOs focused on short-term operational demands versus long-term optimization
EAs will have to go through various stages of maturity before their job potential is fulfilled
The EA role is not defined well enough to model and operate a successful EA organization

This last bit was interesting, but didn’t really flow from the remainder of the presentation, which presented the IT architect job and pay survey results.

Minaz Sarangi, TD Bank, on EA in financial services #ogtoronto

I still haven’t posted my notes from yesterday – I made the mistake of not bringing my laptop yesterday, and my notes are trapped in my paper notebook until I get a chance to review and transcribe them.

I only caught the last 10 minutes of Minaz Sarangi’s presentation due to a meeting elsewhere, but was able to download the presentation and get caught up in time for the Q&A. TD has grown significantly through mergers and acquisitions, including the major acquisition of Canada Trust in 2000, and a big part of their enterprise architecture efforts are to standardize across the various IT infrastructures that exist in the subsidiaries in order to simplify the platforms. This is not fundamentally different from most large financial services, although in many cases, the acquired companies are run as siloed business units, leading to inefficiencies and inability to provide a complete customer view across all product lines.

TD, in developing a true enterprise architecture strategy that spans all the business units, is having the business strategy guide their EA efforts and their enterprise technology strategies. They’ve developed architecture domain practices for business, applications, data, security and technology, and define prescriptive architectures in order to align solutions delivery with their enterprise standards. All of the technology building blocks are defined in the context of the EA, and each has both a strategy and a reference architecture in order to articulate the current and future state, the roadmap, current and future capabilities required, deployed solutions associated with the capabilities, reference implementations, and technology standards.

From a business standpoint, the key goals are to make employees more productive and to enhance customer experience, but there’s also issues of risk reduction, security, system availability and cost reductions due to standardized technology platforms.

How TD is achieving this is through what they call “EA simplification”:

Reduction of operational footprint for greater agility, through application rationalization and enterprise shared services
Consolidation and standardization of core technology platform for scalability
Automation of repetitive architectural and engineering processes for sustainability, for risk reduction and process optimization

They’re starting to see some success with this approach, but as can be expected from such a diverse organization, it’s slow going. They have some enterprise shared services, including content management, and are getting the sponsorship and commitment in place that they require to push forward.

I’m of two minds about programs like this: I certainly see the need for technology standardization within an organization, but it seems like some of these massive EA efforts serve to just extend the delays for new technology implementation and create a significant set of rapids in advance of the still very waterfall methodologies.