Skip to content

{ Category Archives } EA

Deciding on process modeling tools #GartnerBPM

Bill Rosser presented a decision framework for identifying when to use BPA (business process analysis), EA (enterprise architecture) and BPM modeling tools for modeling processes: all of them can model processes, but which should be used when?

It’s first necessary to understand why you’re modeling your processes, and the requirements for the model: these could be related to quality, project validation, process implementation, as part of a larger enterprise architecture modeling effort and many other reasons. In the land of BPM, we tend to focus on modeling for process implementation because of the heavy focus on model-driven development in BPMS, hence model within our BPMS, but many organizations have other process modeling needs that are not directly related to execution in a BPMS. Much of this goes back to EA modeling, where several levels of process modeling that occur in order to fulfill a number of different requirements: they’re all typically in one column of the EA framework (column 2 in Zachman, hence the name of this blog), but stretch across multiple rows of the framework such as conceptual, logical and implementation.

Different types and levels of process models are used for different purposes, and different tools may be used to create those models. He showed a very high-level business anchor model that shows business context, a conceptual process topology model, a logical process model showing tasks within swimlanes, and a process implementation model that looked very similar to the conceptual model but included more implementation details.

As I’ve said before, introspection breeds change, and Rosser pointed out that the act of process modeling reaps large benefits in process improvement since the process managers and participants can now see and understand the entire process (probably for the first time), and identify problem areas. This premise is what’s behind many process modeling initiatives within organizations: they don’t plan to build executable processes in a BPMS, but model their processes in order to understand and improve the manual processes.

Which type of process modeling tool to useProcess modeling tools can come in a number of different guises: BPA tools, which are about process analysis; EA tools, which are about processes in the larger architectural context; BPM tools, which are about process execution; and process discovery tools, which are about process mining. They all model processes, but they provide very different functionality around that process model, and are used for different purposes. The key problem is that there’s a lot of overlap between BPA, EA and BPM process modeling tools, making it more difficult to pick the right kind of tool for the job. EA tools often have the widest scope of modeling and analysis capabilities, but don’t do execution and tend to be more complex to use.

He finished by matching up process modeling tools with BPM maturity levels:

  • Level 1, acknowledging operational inefficiencies: simple process drawing tools, such as Visio
  • Level 2, process aware: BPA, EA and process discovery tools for consistent process analysis and definition of process measurement
  • Levels 3 and 4, process control and automation: BPMS and BAM/BI tools for execution, control, monitoring and analysis of processes
  • Levels 5 and 6, agile business structure: simulation and integrated value analysis tools for closed-loop connectivity of process outcomes to operational and strategic outcomes

He advocates using the simplest tools possible at first, creating some models and learning from the experience, then evaluating more advanced tools that cover more of the enterprise’s process modeling requirements. He also points out that you don’t have to wait until you’re at maturity level 3 to start using a BPMS; you just don’t have to use all the functionality up front.

2009 10 05 Sandy Kemsley BPA
Gartner Comments (1)

The Open Group’s Service Integration Maturity Model and SOA Governance Framework

I had a chance last week for a pre-release briefing from The Open Group’s Chris Harding, Forum Director for SOA and Semantic Interoperability, on two new standards that they are releasing today: the Service Integration Maturity Model (OSIMM) and the SOA Governance Framework. These are both vendor-neutral (although several large vendors were involved in their creation), and are available for free on The Open Group’s site. In their words:

OSIMM will provide an industry recognized maturity model for advancing the continuing adoption of SOA and Cloud Computing within and across businesses. The SOA Governance Framework is a free guide for organizations to apply proven governance standards that will accelerate service-oriented architecture success rates.

OSIMM is a strategic planning tool: it is used to assess where you are in your SOA initiatives relative to a standard, vendor-neutral maturity model, and help create a roadmap for how to move on to the higher levels of maturity. At the heart of it is the OSIMM matrix, with maturity levels as columns progressing from left to right, and the different organizational dimensions being measured as rows: business view, governance and organization, methods, applications, architecture, information, and infrastructure and management.

OSIMM Matrix

Within each cell of the matrix are the indicators for that dimension and maturity level: for example, if you’re using object oriented modeling methods, that indicates that your methods are at level 2, whereas using service oriented modeling would move you up to level 4 or 5 in the methods dimension. Behind this matrix, OSIMM includes a full set of maturity indicators and attributes, plus assessment questions that organizations can use to determine where they are in terms of maturity: each dimension can be (and likely will be) at a different level of maturity.

This has the potential to be an incredibly useful self-assessment tool for organizations: rather than the very product-specific measurements that you see from vendors (“Not using our product? Oh, you’re not at all advanced in your SOA efforts…”), this is independent of whatever products that you’re using: it’s more about the type of products, and the methods and governance that you’re using to apply them. You’ll be able to use it to understand services and SOA, assess the maturity of your organization, and develop a roadmap to reach your goals.

The first version of the OSIMM Technical Standard will be available here for free download, although that link was still not working at the time that I wrote this. Other industry-specific standards organizations are free to use OSIMM directly, or extend it with their own dimensions and indicators as required.

The other major announcement today is about the SOA governance framework, which helps an organization to define their governance processes and methods. This is more of a practical framework for defining policies aligned between business and IT, aiding communication and capturing vendor-neutral best practices. This includes best practices around both lifecycle management and portfolio management, for both services and service-based solutions.

Governance Processes

Lifecycle and portfolio management are quite different: for example, a service lifecycle would include the idea or motivator for the service, the service definition, service creation, putting the service into operation, modifying and maintaining the service, and eventually retiring the service from operation. Service portfolio management is more concerned with reusability, and the practice of looking in the portfolio in the early stages of service lifecycle to see if there is an existing service that suits the requirements. The same applies to solution lifecycle and portfolio management; this differs from any other type of solution governance since there may be service-specific issues such as composition to be considered.

This generic reference model for SOA governance is provided as a standard, to be used by companies to create (and constantly monitor and update) their own specific governance model and best practices. The SOA governance framework may be used in the context of another governance framework, such as COBIT or ITIL; the SOA working group did a mapping of COBIT to this framework as part of the framework development process, and plan to do more in the future in order to help organizations preserve their investment in COBIT/ITIL training and implementation.

The SOA Governance Framework will be available here for free download.

2009 08 24 Sandy Kemsley SOA Comments (2)

Enterprise Architects in the cloud

A couple of weeks ago, I attended the Open Group’s Enterprise Architecture conference in Toronto (my coverage here), and ended up being invited to speak on Dana Gardner’s panel on how the cloud is pushing the enterprise architects’ role beyond IT into business process optimization.

You can now find the podcast here, subscribe to the Briefings Direct podcast series on iTunes here, and read the transcript here.

2009 08 07 Sandy Kemsley Open Group Comments (0)

Dana Gardner’s panel on EA skills in a downturn #ogtoronto

I was in a panel here on Monday, hosted by Dana Gardner and also including John Gøtze of the Association of Enterprise Architects, and Tim Westbrock of EAdirections, where we discussed the issues of extending the scope of architecture beyond the enterprise. This was recorded and will be included in Dana’s usual podcast series within a couple of weeks; I’ll post a link to it when I see it, or you can subscribe in iTunes and catch it there..

Today, he’s moderating two more panels, and I sat in on the beginning of the one about which skills and experience differentiate an enterprise architect in a downtown, although I unfortunately had to duck out to a client meeting before the end (the disadvantage of attending a conference in my home city). This one featured James de Raeve and Len Fehskens of The Open Group, David Foote of Foote Partners, and Jason Uppal of QRS. From the conference program description:

As the architect’s role continues to evolve in scope with the increasingly global and distributed enterprise so to do the core skills and experiences required of them. Professional certifications, such as ITAC, ITSC and TOGAF, can be career differentiators at any time, but are particularly crucial during periods of economic downturn such as we’re currently experiencing.

This panel will examine the evolving job requirements of today’s enterprise architect, discuss the value of professional certification programs and how certifications help to not only legitimize and validate the profession, but also provide much-needed demand for the skills, capabilities and experience that certified professionals have within their organizations.  The panel will also include perspectives on how certification can affect market demand and salary levels for those certified.

It’s almost impossible to capture everything said on a panel or who said what, so just a few unattributed comments:

  • A lot of organizations are in panic mode, trying to cut costs but not lose (any more) customers; IT is afraid of being blamed for costs and inefficiencies
  • There needs to be more coherence around the definition of EA so that this position doesn’t get squeezed out during budget cuts due to lack of common understanding of what EAs do (I’m thinking it’s a bit late for that)
  • Issues in governance are becoming critical; architects need to have knowledge and skills in governance in order to remain relevant
  • Architects need to have the low level technical skills, but also have to develop the higher-level strategic and collaborative skills
  • Many organizations don’t have a career development framework in place to develop an EA team
  • In many cases, you will need to perform the role of architect before anyone is willing to call you that (that seems obvious to me): it’s as much about experience as about any sort of certification
  • HR doesn’t, in general, understand what an architect does, but sees it as just a fancy title that you give to someone in IT instead of giving them a raise (much the way that we used to give them the “project manager” title 15 years ago)

I hated to leave mid-session, but I’ll catch the replay on Dana Gardner’s Briefings Direct in a couple of weeks. I’m hoping to be back for at least some of the panel later today on cloud security, and likely stick around for CloudCamp tonight.

2009 07 22 Sandy Kemsley Open Group Comments (2)

Cloud Computing Business Scenario Workshop #ogtoronto

I’ve never attended an Open Group event before, but apparently interactive customer requirements workshops are part of what they do. We’re doing a business scenario workshop to gather requirements for cloud computing, led by Terry Blevins of MITRE, also on the board of the Open Group. The goal is to capture real business requirements, with the desired outcome to have the vendors understand and respond to customers’ needs. The context presented for this is a call to action for cloud vendors to develop and adhere to open standards, and we were tasked with considering the following questions:

  • What are the pain points and ramifications of not addressing the pain points, relative to cloud computing?
  • What are the key processes that would take advantage of cloud computing?
  • What are the desired objectives of handling/addressing the pain points?
  • Who are the human actors and their roles?
  • What are the major computer actors and their roles?
  • What are the known needs that cloud computing must fulfill to help improve the processes?

We started with brainstorming on the pain points: in the context of cloud computing, given my critical use of Google Apps and Amazon S3, I found myself contributing as an end user. My key pain point (or it was, before I solved it) was the risk of losing data in a physical disaster such as fire/flood/theft and the need for offsite backup. There were a ton of other pain points:

  • Security – one person stated that their security is better since moving to cloud applications
  • Sizing and capacity
  • Flexibility in bundling and packaging their own products for selling
  • Complex development environments
  • Pressure to reduce capital investments
  • Operating costs
  • Ineffective support
  • Functional alignment to business needs
  • Need to align IT with business
  • Cost of physical space and energy (including green concerns)
  • Cost of failure discourages innovation
  • Compliance standards
  • Difficulties in governance and management
  • Incremental personnel costs as applications are added
  • Infrastructure startup cost barrier
  • Time to get solutions to market
  • Hard to separate concerns
  • Operational risk of using old equipment
  • Resource sharing across organizations
  • No geographic flexibility/location independence
  • Training cost and time
  • Loss of control by users provisioning cloud resources on their own
  • No access to new technology
  • Dependency on a few key individuals to maintain systems
  • Being stifled by in-house IT departments
  • Need to understand the technology in order to use it
  • Do-it-yourself in-house solutions
  • Lack of integrated, well-managed infrastructure
  • Overhead of compliance requirements, particularly in multinational context
  • Long time to market
  • Disposal costs of decommissioned systems
  • Cost of help desk
  • Legal/goodwill implications of security breaches
  • Can’t leverage latest ideas

This is a rough list thrown out by audience members, but certainly lots of pain here. This was consolidated into 9 categories:

  1. Resource optimization
  2. Cost
  3. Timeliness
  4. Business continuity (arguably, this is part of risk)
  5. Risk
  6. Security
  7. Inability to innovate
  8. Compliance
  9. Quality of IT

Things then got even more participatory: we all received 9 post-it notes, giving us 9 votes for these categories in order to collaboratively set priorities on them. We could cast all of our votes for one category, vote once for each category, or anything in between; this is intended to be from our own perspective, not our customers or what we feel is best for enterprises in general. For me, the key issues are business continuity and security, so I cast three votes for each. Cost is also important, so I gave it two votes, and timeliness got one vote. I’ve seen this same voting technique used before, but never with so much ensuing confusion over what to do. :) Blevins pointed out that it sometimes works better to hand out (fake) money, since people understand that that they’re assigning value to the ideas if they’re dividing up the money between them.

The three winners were 1, 2, and 3 from the original list, which (no surprise) translate to better, cheaper and fast. The voting fell out as follows:

Category # of votes
Resource optimization 37
Cost 34
Timeliness 41
Business continuity 8
Risk 20
Security 29
Inability to innovate 29
Compliance 17
Quality of IT 16

Great session, and some really good input gathered.

2009 07 22 Sandy Kemsley Open Group
cloud Comments (1)

TOGAF survey results #ogtoronto

Another flashback to Monday, when Jane Varnus of Bank of Montreal and Navdeep Panaich of Capgemini presented the results of a survey about TOGAF 9. They covered a lot of stats about EAs and their organizations, a few of which I found particularly interesting:

  • Architects form 2-4% of IT staff (the fact that the question was asked this way just reinforces the IT nature of architecture)
  • Most architecture practices started within the past 4-5 years
  • 65% of architecture initiatives are charged centrally rather than to individual projects
  • More than 60% of architecture groups are sponsored by the CTO or CIO, and more than 70% report up to the CTO or CIO
  • EAs have surprisingly low levels of responsibility and authority and decision-making in both enterprise efforts and projects, but are usually involved or consulted
  • The primary driver for EA, with 44%, is business-IT alignment; better strategic planning and better IT decision-making come in next at 11% each
  • Business-IT alignment is also one of the key benefits that companies are achieving with EA; when they look at the future desired benefits, this expands to include agility, better strategic planning, and better IT decision-making
  • 32% of organizations have no KPIs for measuring EA effectiveness, and another 34% have 1-5 KPIs
  • More thought needs to be given to EA metrics: 40% of the KPIs are perception-oriented (e.g., stakeholder satisfaction), 33% are value-oriented (e.g., cost reduction) and 26% are activity-oriented (e.g., number of artifacts created)
  • EA frameworks are not yet used in a standardized fashion: 27% are using a standard architecture framework in a standardized manner (this is from a survey of Open Group members!), 44% have selected a framework but its use is ad hoc, and 27% select and use frameworks on an ad hoc basis
  • TOGAF (8 and 9 combined) is the predominant framework, used in more than 50% of organizations, with Zachman coming in second at 24%
  • Drivers for architect certification are unclear, and many organizations don’t require it

There’s a ton of additional information here; the whole presentation is here (direct PDF link), although it may be taken down after the conference.

2009 07 22 Sandy Kemsley Open Group Comments (0)

Ndu Emuchay, IBM, on standards in cloud computing #ogtoronto

Today has an track devoted mostly to cloud computing, and we started with Ndu Emuchay of IBM discussing the cloud computing landscape and the importance of standards. IBM is pretty innovative in many areas of new technology – I’ve blogged in the past about their Enterprise 2.0 efforts, and just this morning saw an article on what they’re doing with the internet of things where they’re integrating sensors and real-time messaging, much of which would be cloud-based, by the nature of the objects to which the sensors are attached.

He started with a list of both business and IT benefits for considering the cloud:

  • Cost savings
  • Employee and service mobility
  • Responsiveness and agility in new solutions
  • Allows IT to focus on their core competencies rather than running commodity infrastructure – as the discussion later in presentation pointed out, this could result in reduced IT staff
  • Economies of scale
  • Flexibility of hybrid infrastructure spanning public and private platforms

From a business standpoint, users only care that systems are available when they need them, do what they want, and are secure; it doesn’t really matter if the servers are in-house or not, or if they own the software that they’re running.

Clouds can range from private, which are leased or owned by an enterprise, to community and public clouds; there’s also the concept of internal and external clouds, although I’m not sure that I agree that anything that’s internal (on premise) could actually be considered as cloud. The Jericho Forum (which appears to be part of the Open Group) publishes a paper describing their cloud cube model (direct PDF link):

Jericho Forum's Cloud Cube Model

There’s a big range of cloud-based services available now: people services (e.g., Amazon’s Mechanical Turk), business services (e.g., business process outsourcing), application services (e.g., Google Apps), platform services and infrastructure services (e.g., Amazon S3); it’s important to determine what level of services that you want to include within your architecture, and the risks and benefits associated with each. This is a godsend for small enterprises like my one-person firm – I use Google Apps to host my email/calendar/contacts, synchronized to Outlook on my desktop, and use Amazon S3 for secure daily backup – but we’re starting to see larger organizations put 10’s of 1000’s of users on Google Apps to replace their Exchange servers, and greatly reduce their costs without compromising functionality or security.

Emuchay presented a cloud computing taxonomy from a paper on cloud computing use cases (direct PDF link) that includes hosting, consumption and development as the three main categories of participants.

Cloud Computing Taxonomy

There’s a working group, organized using a Google Group, that developed this paper and taxonomy, so join in there if you feel that you can contribute to the efforts.

As he points out, many inhibitors to cloud adoption can be addressed through security, interoperability, integration and portability standards. Interoperability is the ability for loose coupling or data exchange between that appear as a black box to each other; integration combines components or systems into an overall system; and portability considers the ease of moving components and data from one system to another, such as when switching cloud providers. These standards impact the five different cloud usage models: end user to cloud; enterprise to cloud to end user; enterprise to cloud to enterprise (interoperability); enterprise to cloud (integration); and enterprise to cloud (portability). He walked through the different types of standards required for each of these use cases, highlighting where there were accepted standards and some of the challenges still to be resolved. It’s clear that open standards play a critical role in cloud adoption.

2009 07 22 Sandy Kemsley Open Group
cloud Comments (4)

Alain Perry, Treasury Board Secretariat, on EA in Canadian government #ogtoronto

Also on Monday, we heard from Alain Perry from the CIO branch of the Treasury Board Secretariat on how enterprise architecture, supported by the use of TOGAF, is making its way into the Canadian government at all levels. The EA community of practice is supporting the use of TOGAF 9 in order to enable a common vocabulary and taxonomy for creating and using architectural artifacts, and to create reusable reference models, policy instruments and standards to support the architectural work.

Using the classic “city planning” analogy that we hear so often in EA discussions, Perry showed how they break down their levels of detail into strategic/enterprise architecture (“city scapes”) for vision and principles required for long-term direction, program/segment architecture (“district designs”) for specific programs and portfolios to provide context for solution architectures, and solution architecture (“detailed building design and specs”) for a specific project.

They used an adaptation of TOGAF to create the common content model for each of those three levels: architecture vision, architecture requirements, business architecture, architecture (including data and application architecture), technology architecture, and architecture realization.

They’ve created the Canadian Governments Reference Model (CGRM) that allows different levels of government to share standards, tools and capabilities: in Canada, that includes at least federal, provincial and municipal, plus sometimes regional, all with their own political agendas, so this is no mean feat.

2009 07 22 Sandy Kemsley Open Group Comments (0)

Allen Brown of Open Group on their internal use of TOGAF #ogtoronto

I was taking notes in a paper notebook at the conference on Monday, and only now have had time to review them and write up a summary.

The general sessions opened with Allen Brown of the Open Group discussing their own use of TOGAF in architecting their internal systems. Since they’re making a push to have TOGAF used in more small and medium businesses, using themselves as a test case was an excellent way to make their point. This seemed to be primarily a systems architecture exercise, responding to threats such as operational risk and security; however, the problem that they had was primarily that of systems, not of the general organizational strategy.

So far, as part of the overall project, they’ve replaced their obsolete financial system, outsourced credit card handling, moved to hosted offsite servers, added a CRM system, and are adding a CMS to reduce their dependency on a webmaster for making website updates. These are all great moves forward for them, but the interesting part was how they approached architecture: they involved everyone in the organization and documented the architecture on the intranet, so that everyone was aware of what was happening and the impacts that it would have. Since this included business priorities and constraints, the non-technical people could contribute to and validate the scenarios, use cases and processes in the business architecture.

They developed a robust set of architecture artifacts, documenting the business, applications, data and technology architectures, then identified opportunities and solutions as part of an evaluation report that fed into the eventual system implementations.

This was a great case study, since it showed how to incorporate architecture into a small organization without a lot of resources. They had no budget to hire new staff or invest in new tools, and had to deal with the reality of revenue-generating work taking precedence over the architecture activities. They weren’t able to create every possible artifact, so were forced to focus on the ones most critical to success (a technique that could be used well in larger, better-funded organizations). Yet they still experienced a great deal of success, since TOGAF forced them to think at all levels rather that just getting mired in the technical details of any of the specific system upgrades: this resulted in appropriate outsourcing and encouraged reuse. At the end of the day, Brown stated that they could not have achieved half of what they have without TOGAF.

2009 07 22 Sandy Kemsley Open Group Comments (0)

Heather Kreger, IBM, on SOA standards

SOA standardsIt’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

SOA-enabled Business Transformation FrameworkThey 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.

2009 07 21 Sandy Kemsley BPM standards
Open Group
SOA Comments (1)

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.

2009 07 21 Sandy Kemsley Open Group Comments (0)

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.

2009 07 21 Sandy Kemsley Open Group
business Comments (2)

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.

2009 07 21 Sandy Kemsley Open Group Comments (3)

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.

2009 07 21 Sandy Kemsley Open Group Comments (0)

The Open Group Conference

I was already planning to attend the Open Group Conference in Toronto next week to catch up on what’s happening in the enterprise architecture space, and now I’ve been invited to join Dana Gardner’s panel on Monday morning, which will also be recorded as a podcast. The panel is on architecture’s scope extending beyond the enterprise, bringing together elements of EA, SOA and cloud computing. Also on the panel will be John Gotze, president of the Associate of Enterprise Architects, and Tim Westbrock from EAdirections. There are big aspects of business process to this, specifically when you start orchestrating processes that span the enterprise’s boundaries, and I hope that we’ll have time to explore that.

I’ll probably be at the conference each day to check out some of the other sessions, and I may stick around for some of the evening events, such as CloudCamp on Wednesday. If you’re there, drop by my session and say hi.

2009 07 17 Sandy Kemsley SOA
cloud Comments (0)

TOGAF V9 Enterprise Edition

I recently had a briefing from The Open Group’s CEO Allen Brown and Judith Jones, CEO of the UK-based consultancy Architecting the Enterprise, on the new version of the TOGAF enterprise architecture framework announced today.

For those of you not up on your enterprise architecture, TOGAF is a product of The Open Group, a standards consortium that’s been around for more than 25 years, with 7,800 participants in 350 different enterprises, including both end-customer organization and vendors. By allowing each enterprise to have only one vote, it tends to level the playing field and allow smaller vendors and customers to have just as much of a voice as large vendors that might normally dominate standards development.

The TOGAF framework is seeing widespread usage since it works together with other EA frameworks and concepts such as model-driven architecture, rather that competing with them. They’ve been seeing a growing demand for TOGAF 8 certified people, of which there are about 9,000 worldwide.

TOGAF 9 was developed in response to the needs of The Open Group’s members:

  • Closer alignment with the business
  • Simple implementation and greater usability
  • Evolution rather than revolution in order to preserve value in existing investments

Version 9 has a number of new features over version 8:

  • Further detail on the Architectural Development Method (the diagram of interconnected circles with activities A-H surrounding Requirements Management), including guidelines and techniques on its usage.
  • Modular structure, promoting incremental adoption and greater usability.
  • Content framework, providing a Zachman-like categorization framework for EA artifacts; in fact, they have a mapping between TOGAF and Zachman since these might be used in the same environment.
  • Explicit consideration of architecture styles, e.g., SOA.

They’ve added quite a bit more material to TOGAF in this version, plus enhanced certifications. The certification program for TOGAF 9 is exam-based (rather than the current training-based certification with an optional exam), with 2 levels of certification: foundation and advanced. There’s also an exam to recertify people from TOGAF 8 to 9.

The biggest adoption for TOGAF has been in the UK and North America, which is likely driven in part by language translation of the materials, but there are other organizations in Europe, Australia and Asia starting to use it as well.

2009 02 02 Sandy Kemsley Comments (4)

Appian Forum: MEGA Partnership

Terry Lee, MEGA’s VP of North American operations, gave us an overview of MEGA, both in terms of their business process analysis and enterprise architecture capabilities. He stated the real reason for using a BPA tool, rather than just the modeling environment within the BPMS, is the ability to analyze the processes within a larger context: relative to risk analysis, enterprise architecture, and corporate performance management.

A process is analyzed and some level of design is completed in MEGA, then the process is handed off to Appian through a manual export/import for further work in their process designer — no mention of round-tripping, although I happened to be sitting beside Dan Hebda (MEGA’s VP of technology) and passed him a note asking about this. He replied that round-tripping would be supported, but isn’t in the current prototype that they’re demonstrating here at the conference. I have a meeting with Dan tomorrow at Gartner, where I’m sure to get a lot more information on this, and Terry summed at the end of his presentation by mentioning that the future integration would include round-tripping.

Metrics for the executing process are captured using the MEGA Advisor and fed back to the models in MEGA to allow for process analysis and optimization.

I believe that there’s a lot of benefit for many organizations in using a BPA tool such as MEGA for modeling processes — especially the portions of processes that are not automated, hence may not be represented in the process models within a BPMS — and the larger enterprise architecture context. For success, however, this requires two key areas of integration: a seamless bidirectional exchange of process models, and the ability to load executing process logging data back into the BPA. It appears that Appian and MEGA are working hard to achieve both of these.

Tagged ,
2008 09 09 Sandy Kemsley AppianForum
BPA Comments (2)

Architecture & Process: Jaakko Riihinen

Jaakko Riihinen, head of enterprise architecture for Nokia Siemens Networks, spoke about business process architecture: a deep dive into the details of one set of models that they use in their EA efforts. He started with definitions of architecture, process and abstract modeling, reinforcing that a presentation view of a model is just a view, not the entire model. In his definition of architecture, I especially like the analogy that he made of architecture being the external energy that keeps systems within an organization from evolving into chaos. In general, architectures tend to satisfy nonfunctional requirements, such as optimization of system economics.

One of the issues in modeling processes is the different types of models that may be used in different departments, and the ultimate goal is to have a set of process models for the entire organization rather than having them be constructed piecemeal. He characterizes processes in three types: transactional, creative (team collaboration on work product), and community (dynamic, self-organizing); the modeling method that is the focus of this presentation addresses transactional processes.

He shows three elements of their process architecture:

  • A process integration model, showing the high-level view of how processes and work products interact. This is the functional design of the process architecture.
  • A process behavior model, which is a standard swimlane process model that shows the detailed view of one of the process nodes from the process integration model. It’s different from BPMN in that the work products are shown within the sequence flow rather than attached as artifacts since they are focused on linking the activities closely to what triggers them and what they produce.
  • Work instructions for performing one activity in a process.

Other characteristics of a process are also modeled:

  • Process instantiations, which can be scheduled or event-driven; where event-driven can be based on work product (e.g., inbound document) or an explicit event (e.g., timeout).
  • Execution constraints, either a free-running schedule (activities execute as soon as inputs are available) or an imposed schedule (e.g., periodic reporting)

The process integration model shows the instantiation methods for each process, as well as showing how multiple processes can provide input to another process in a variety of ways, including both informational and triggering.

All of this provides the notational background to discuss the real issue: normalization of process models and process architecture, using methods derived from classic systems methodologies such as control system theory and critical path analysis. The benefits of normalization include unambiguous definitions that are easier to understand, and better recognition and reuse of process patterns, but the real benefit is that this turns process architecture from an art to a science. There are four basic rules for process architecture normalization:

  • Structural integrity: closing alternative paths within parallel paths, and closing parallel paths within alternative paths (these are basic topology constraints from graph theory, and would be enforced by most process modeling tools anyway)
  • Functional cohesion: no disconnected activities
  • Temporal cohesion: no synchronous processing by activities outside the process (which implies that you would not use the BPMN method of separate pools for separate organizations since messaging between pools would not be allowed, but would consider that separate organization’s activities to be part of the process if your internal process needs to wait for a response from the other organization before continuing the process)
  • Modularity: activities or roles having different cardinalities belong to separate processes (this helps to determine the boundaries between processes, e.g., sets of activities that pertain to the entire company are usually in separate processes from those for individual business units), variance at the process level (when alternative paths in a process become sufficiently complex or encompass most of the process, create two variants of the process), variance at the integration model level, deployment details, process components (subprocesses shared between processes)

Determining the boundaries of a single process may involve combining what are considered to be separate processes into one: we discussed the example of employee onboarding, which involves several departments but is really a single process. Looking at the triggers for activities and processes also helps to determine the boundaries: activities that asynchronously create work products that are consumed by other activities are usually in a separate process, for example, as are activities that are performed on different schedules.

They’re using ARIS, and have configured their own metamodel for the process integration model and behavior model. Riihinen is also interested in developing automated methods for normalizing process models.

His slides are incredibly dense with information, and fascinating, so I suggest that you check them out for more details on all of this. In particular, check out the slides that show examples of the four process normalization rules.

As you can tell by the above URL, the conference is using Slideshare to publish (but not allow downloads of) all presentations here.

2008 04 23 Sandy Kemsley Architecture&Process Comments (0)

Architecture & Process: Robert Pillar

The first breakout session of the day was on connecting BPM, SOA and EA for enterprise transformation, with Robert Pillar of Microsoft. He’s talking about how compliance is the key driver to the coalition of BPM, SOA and EA, but that the coalition starts with holistic collaboration. There are barriers to this:

  • Organizational barriers: IT organizations and silos between EA, SOA and BPM groups
  • Cultural barriers: lack of understanding the business value, lack of understanding the concepts, and old-style mentality
  • Political barriers: resistance to change
  • Collaboration barriers: resistance to meetings and collaboration

Risks and benefits must be measured.

At this point, someone in the audience spoke up and said "we understand all this, can you just skip ahead to any solutions to these issues that you have to present?" Incredibly rude, and really put the speaker on the spot, but he had a point.

He had a summary slide on why to choose SOA:

  • It offers a focus on business processes and goals: supports customer centric view of the business, allows design of solutions that keep requirement changes (agility) in mind
  • It offers an iterative and incremental approach following EA and BPM initiatives: make change happen over time, allow employees learn about the concept of services
  • It offers a means to reap the benefits of existing investments on technology: reuse IT resources, focus on business problems without being entangled in the technology

He sees EA and BPM as leading us to SOA, which is a valid point: if you do EA and BPM, you’ll definitely start to do SOA. However, I see many organizations starting with SOA in the absence of either EA or BPM.

2008 04 23 Sandy Kemsley Architecture&Process
BPM
SOA Comments (6)

Architecture & Process: Rob Cloutier

The disadvantage of a small conference is that speakers tend to drop out more frequently than you’ll find in large conferences, and this afternoon my first choice didn’t show. However, it had been a tough choice in any case, so I was happy to attend the session with Rob Cloutier of Stevens Institute of Technology on patterns in enterprise architecture.

The analysis of patterns has been around along time in mathematics and engineering, but they’re often difficult to capture and reuse in real life. There are some real business drivers for enterprise architecture patterns: much of the knowledge about systems is still gathered through artifacts, not patterns, making it difficult to reuse on other projects. It also tends to control complexity, since systems are based on standard patterns, and creates a common syntax and understanding for discussing projects. This has the impact of reducing risk, since the patterns are well understood.

Patterns are not created, they’re mined from successful projects by determining the elements contributing to the success of the projects.

In an enterprise architecture sense, there’s the issue of the level of these patterns; Cloutier’s premise is that you define and use patterns relative to your scope within the architecture, so may be a system architecture pattern. He laid out a topology of patterns relative to the views within the Zachman framework: organization, business and mission patterns at the contextual/scope level; structure, role, requirements, activities and system processes at the conceptual/enterprise model level, system analysis, system design, system test, software architecture, software analysis, software requirements, hardware requirements, hardware design and operational patterns at the logical/system model level, and so on. He focused primarily on the five patterns in the enterprise model level.

He walked through an example with use cases, generalizing the purchase of a specific item to the purchase of any product: the actors, functions and data flow can be generalized, then adapted to any similar system or process by changing the names and dropping the pieces that aren’t relevant. He listed the characteristics of a pattern that need to be documented, and pointed out that it’s critical to model interfaces.

He showed the analysis that he had done of multiple command-and-control systems to create a command-and-control pattern containing four basic steps in an IDEF model — plan, detect, control and act — with the input, outputs, strategy and resources for each step. In fact, each of those steps was itself a pattern that could be used independently.

He had an interesting analogy of the electricity and distribution system as a service-oriented architecture: you can plug in a new device without notifying the provider, you might be served by multiple electricity producers without knowing, your usage is metered for your service provider to bill you for the usage, and the details of how electricity is generated is generally not known to you.

Like any enterprise architecture initiative, the development of EA patterns is often considered overhead in organizations, so may never be done. You have to take the time up front to discover and document the pattern so that it can be reused later; it’s at the first point of reuse where you start to save money, and subsequent reuses where it really starts to pay off. Although many examples of software patterns exist, enterprise architecture patterns are much rarer: Cloutier is researching the creation of an EA pattern repository in his work at Stevens Institute of Technology. Ultimately, the general availability of enterprise architecture patterns that have been created by others — a formalization of best practices — is where the real benefits lie, and can help to foster the acceptance of EA in more organizations.

2008 04 22 Sandy Kemsley Architecture&Process Comments (0)