Category Archives: Enterprise Architecture

Creating Reference Architecture: The Center of Excellence

By Serge Thorn, Architecting the Enterprise

This is the second installment of a three-part series discussing how to implement SOA through TOGAF®. In my first blog post I explained the concept of the Center of Excellence, and creating a vision for your organization.

The SOA Center of Excellence (CoE) will need to define a Reference Architecture for the organization.

A Reference Architecture for SOA is an abstract realization of an architectural model showing how an architectural solution can be built while omitting any reference to specific concrete technologies. Reference Architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying components and capabilities that must be present for it to perform. The capabilities are normally captured into layers, which in their own right require an architectural definition. However, the specific choice of the components representing the capabilities is made after various business and feasibility analysis are performed. A Reference Architecture can be used to guide the realization of implementations where specific properties are desired of the concrete system.

The purpose of the Reference Architecture is reflected in the set of requirements that the Reference Architecture must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the critical success factors that ensure their satisfaction.

A Reference Architecture for SOA describes how to build systems according to the principles of SOA. These principles direct IT professionals to design, implement, and deploy information systems from components (i.e. services) that implement discrete business functions. These services can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both IT and business organizations.

Using the pattern approach the SOA Reference Architecture is a means for generating other more specific reference architectures, or even concrete architectures depending on the nature of the patterns. Or to put it another way, it is a machine for generating other machines.

The Open Group SOA Reference Architecture (SOA RA) standard is a good way of considering how to build systems.

The SOA CoE needs also to define the SOA lifecycle management that consists of various activities such as governing, modelling, assembling, deploying and controlling/monitoring.

Simply put, without management and control, there is no SOA only an “experience”. The SOA infrastructure must be managed in accordance with the goals and policies of the organization, which include hardware and software IT resource utilization, performance standards as well as goals for service level objectives (SLOs) for the services provided to IT users as well as business goals and policies for businesses that run and use IT. To be truly agile, enactment of all these different types of policies requires automated control that allows goals to be met with only the prescribed level of human interaction.

For every layer of the SOA infrastructure a corresponding Manage and Control component needs to exist / be in place. Moreover, the “manage and control” components must be integrated in a way that they can provide an end-to-end view of the entire SOA infrastructure.

These manage and control functions provide the run-time management and control of the entire enterprise IT execution environment.  This includes all of the enterprise’s business processes and information services, including those associated with the IT organization’s own business processes.

The “Principle of Service orientation” must exist as defined in the TOGAF® 9.1 Framework in section 22.7.1.1 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.

Needs and capabilities are not mechanisms in the SOA Reference Architecture. They are the guiding principles for building and using a particular SOA. Nonetheless, the usefulness of a particular SOA depends on how well the needs and capabilities are defined, understood, and satisfied.

Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.

Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles for architecture design or service definition are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behaviour for the style of design.

In the third and final installment of this series I will discuss how to relate SOA principles back to business objectives and key architecture drivers.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

Comments Off

Filed under Cloud/SOA, Enterprise Architecture, Standards, TOGAF, TOGAF®

Implementing SOA through TOGAF 9.1: The Center Of Excellence

By Serge Thorn, Architecting the Enterprise

This is the first installment of a three-part series discussing how to be successful in implementing an SOA initiative through TOGAF® 9.1.

Service-oriented architecture (SOA) has at times been challenged, but it is now on the verge of mainstream acceptance. It now shows maturity, success and even signs of popularity. SOA is an enterprise-scale architecture for linking resources as needed. These resources are represented as business-aligned services, which can participate and be composed in a set of choreographed processes to fulfil business needs.

In 2012, the use of SOA for pivotal emerging technologies, especially for mobile applications and cloud computing, suggests that the future prospect for SOA is favourable. SOA and cloud will begin to fade as differentiating terms because it will just be “the way we do things”. We are now at the point where everything we deploy is done in a service-oriented way, and cloud is being simply accepted as the delivery platform for applications and services. Many Enterprise Architects are also wondering if the mobile business model will drive SOA technologies in a new direction. Meanwhile, a close look at mobile application integration today tells us that pressing mobile trends will prompt IT and business leaders to ensure mobile-friendly infrastructure.

To be successful in implementing a SOA initiative, it is highly recommended that a company create a SOA Center of Excellence (CoE) and The Open Group clearly explains how this can be achieved through the use of TOGAF® 9.1. This article is based on the TOGAF® 9.1 Framework specification and specifically the sections 22.7.1.3 Partitions and Centers of Excellence with some additional thoughts on sections 22.7.1.1 Principle of Service-Orientation and 22.7.1.2 Governance and Support Strategy.

I have looked at the various attributes and provided further explanations or referred to previous experiences based on existing CoEs or sometimes called Integration Competency Centers.

The figure below illustrates a SOA CoE as part of the Enterprise Architecture team with domain and solution architects as well as developers, Quality Assurances (QAs) and Business Architects and Analysts coming from a delivery organization.

Part 1 Image

Establishing a SOA Center of Excellence

The SOA CoE supports methodologies, standards, governance processes and manages a service registry. The main goal of this core group is to establish best practices at design time to maximize reusability of services.

According to the TOGAF 9.1 Framework specification, a successful CoE will have several key attributes, including “a clear definition of the CoE’s mission: why it exists, its scope of responsibility, and what the organization and the architecture practice should expect from the CoE.”

Define a Vision

A SOA CoE must have a purpose. What do we want to achieve? What are the problems we need to solve?

It may sound obvious, but having a blueprint for SOA is critical. It is very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building a SOA is to keep people, including IT and business-side staff focused on the Enterprise Architecture goals.

In order to realize the vision of SOA the following topics should be addressed:

  • What to Build: A Reference Architecture
  • How to Build: Service-Oriented Modeling Method
  • Whether to build: Assessments, Roadmaps, and Maturity Evaluations
  • Guidance on Building: Architectural and Design Patterns
  • Oversight: Governance
  • How to Build: Standards and Tools

The SOA CoE would first have a vision which could be something like:

ABCCompany will effectively utilize SOA in order to achieve organizational flexibility and improve responsiveness to our customers.”

Then a mission statement should be communicated across the organization. Below are a few examples of mission statements:

“To enable dynamic linkage among application capabilities in a manner that facilitates business effectiveness, maintainability, customer satisfaction, rapid deployment, reuse, performance and successful implementation.”

“The mission of the CoE for SOA at ABCCompany is to promote, adopt, support the development and usage of ABCCompany standards, best practices, technologies and knowledge in the field of SOA and have a key role in the business transformation of ABCCompany. The CoE will collaborate with the business to create an agile organization, which in turn will facilitate ABCCompany to accelerate the creation of new products and services for the markets, better serve its customers, and better collaborate with partners and vendors.”

Define a Structure

The SOA CoE also needs to define a structure and the various interactions with the enterprise architecture team, the project management office, the business process/planning and strategy group, the product management group, etc.

The SOA CoE also needs to create a steering committee or board (which could be associated to an architecture board) to provide different types of support:

  • Architecture decision support
    • Maintain standards, templates and policies surrounding Integration and SOA
    • Participate in Integration and SOA design decisions
  • Operational support
    • Responsible for building and maintaining SOA Infrastructure
    • Purchasing registries and products to grow infrastructure
  • Development support
    • Development of administrative packages and services
    • Develop enterprise services based on strategic direction

Define Measurements

According to the TOGAF® 9.1 Framework Specification, “Clear goals for the CoE including measurements and Key Performance Indicators (KPIs). It is important to ensure that the measures and KPIs of the CoE do not drive inappropriate selection of SOA as the architecture style.”

Measurements and metrics will have to be identified. The common ones could be:

  • Service revenue
  • Service vitality
  • Ratio between services used and those created
  • Mean Time To Service Development or Service change
  • Service availability
  • Service reuse
  • Quality assurance

Define Testing Activities

As stated in the TOGAF® 9.1 Framework specification, “The CoE will provide the “litmus test” of a good service.”

Clearly comprehensive testing activities must be described by the SOA CoE. In addition to a set of defined processes related to Web Service Definition Language (WSDL) testing, functional unit testing, regression testing, security testing, interoperability testing, vulnerability testing and load, performance testing, an analysis tool suite may be used to tailor the unique testing and validation needs of Service Oriented Architectures.

This helps test the message layer functionality of their services by automating their testing and supports numerous transport protocols. A few examples include: HTTP 1.0, HTTP/1.1, JMS, MQ, RMI, SMTP, .NET WCF HTTP, .NET WCF TCP, Electronic Data Interchange, ESBs, etc.

Only by adopting a comprehensive testing stance can enterprises ensure that their SOA is robust, scalable, interoperable and secure.

  •  The CoE will disseminate the skills, experience, and capabilities of the SOA center to the rest of the architecture practice.

The Center of Excellence will promote best practices, methodologies, knowledge and pragmatic leading-edge solutions in the area of SOA to the project teams.

  •  Identify how members of the CoE, and other architecture practitioners, will be rewarded for success.

This may sounds like a good idea but I have never seen this as an applied practice.

Define a Skill Set

According to the TOGAF® 9.1 Framework specification, “Recognition that, at the start, it is unlikely the organization will have the necessary skills to create a fully functional CoE. The necessary skills and experience must be carefully identified, and where they are not present, acquired. A fundamental skill for leading practitioners within the CoE is the ability to mentor other practitioners transferring knowledge, skills, and experience.”

Competency and skills building is needed for any initiative. SOA is not just about integrating technologies and applications – it is a culture change within the enterprise, which requires IT to move from being a technology provider to a business enabler. There may be a wide range of skills required such as:

  • Enterprise Architecture
  • Value of SOA
  • Governance model for SOA
  • Business Process Management and SOA
  • Design of SOA solutions
  • Modeling
  • Technologies and standards
  • Security
  • Business communication

It has to be said that lack of SOA skills is the number one inhibitor to SOA adoption.

  • Close-out plan for when the CoE has fulfilled its purpose.

Here again, I am not sure that I have observed any SOA CoE being closed…

In the second installment of this three-part series I will discuss how the Center of Excellence defines a Reference Architecture for the organization.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

Comments Off

Filed under Cloud/SOA, Enterprise Architecture, Standards, TOGAF, TOGAF®

Different Words Meant Different Things, Part 3

By Leonard Fehskens, The Open Group

In the second part of this series, I examined the effect of our definition of enterprise on how we think about EA.

To close, I’ll consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture.

The current cohort of EAs who have grown accustomed to a misnamed and narrowly focused discipline will eventually retire.  They will be replaced, over time, by EAs who learn the discipline in academic programs rather than by making it up on the job.  They will chuckle in amusement at a “body of knowledge” that is like that of medicine before germ theory, geology before plate tectonics, or astronomy before heliocentrism.  These programs are being created now, and academics are not interested in teaching a discipline with an irrational and inconsistent vocabulary.  They don’t want to have to explain to their students that it is for “historical reasons” that “enterprise means the IT part of a business.”

The focus of an academic program on Enterprise Architecture will necessarily reflect the prevailing concept of enterprise.  The commonly used model of Enterprise Architecture being about people, process and technology provides a useful context for considering this influence.

An IT-centric concept of Enterprise Architecture, like the one currently espoused by most of the community, will emphasize the role of information technology in supporting the needs of the business.  It will include just enough about business and people to enable practitioners to address the goal of “aligning IT with the business.”

A concept of Enterprise Architecture based on the idea of enterprise as business will emphasize business, especially business processes, as they are the primary locus of technological support.  It will include just enough about information technology and people to enable practitioners to address the goal of making IT a strategic asset for businesses.

A concept of Enterprise Architecture based on the idea of enterprise as human endeavor will emphasize the role of people, and be built around the sociology and psychology of individuals, groups and organizations, especially leadership and management as means to achieving organizational goals.  It will devote some attention to business as a particular kind of enterprise, but will look at other forms of enterprise and their unique concerns as well.  Finally, it will consider technology in its most general sense as the means of instantiating the infrastructure necessary to realize an enterprise.  There will be a lot of harumphing about how the conventional wisdom is correct by definition because it is what is practiced by the majority of practitioners, but there is a noisy and insistent contingent that will continue to point out that the world is not flat and the sun does not go around the earth.  Only time will tell, but however you measure it, over 90% of most organizations is “not-IT”, and the IT-centric perspective is simply so imbalanced that it can’t ultimately prevail.

Adopting a broader concept of enterprise consistent with its meaning in common English usage does not in any way invalidate any of the current applications or interpretations of Enterprise Architecture.  It simply allows the application of architectural thinking to other kinds of purposeful human activity besides commercial business organizations to be subsumed under the rubric “Enterprise Architecture”.  All entities that are enterprises by these more restrictive definitions clearly fit unchanged into this more inclusive definition of enterprise.

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

12 Comments

Filed under Business Architecture, Enterprise Architecture

Different Words Mean Different Things, Part 2

By Leonard Fehskens, The Open Group

In the first part of this series, I proposed distinct meanings of enterprise, business, organization and corporation.

As I noted earlier, you don’t have to agree with the distinctions I am making here.  But words are a finite, “nonrenewable” resource – if you treat these four words as interchangeable synonyms, you will not be able to make these distinctions without finding other words to make them for you.  In particular, you will not be able to distinguish an endeavor from the means of realizing it (similar to confusing an architecture and a blueprint).  You will not be able to distinguish one particular kind of endeavor (for example, a commercial endeavor) from other kinds of endeavors.  You will not be able to distinguish one particular kind of organization from other kinds of organizations.

Treating these four words as synonyms makes these words unavailable to describe larger and more inclusive domains for the application of architectural thinking.  What’s more, it does so needlessly.  This discipline doesn’t need synonyms any more than an organization needs multiple different systems that do the same thing.  Synonyms are redundancies that reduce the expressive power of the language we use to talk about what we do.  We need to be able to make distinctions between things that are important to distinguish from one another, and there are only so many words available to us to do so.

I acknowledge that for most of the community of practicing business and enterprise architects, most if not all of their practice occurs in the context of business-as-commercial-entities.  It is therefore not surprising that many people in the Business and Enterprise Architecture communities would not believe these distinctions are worth making, and be perfectly happy to (if not insistent that we) treat these words as synonyms.  But we have to be careful to avoid the example of the six blind men and the elephant, and being able to explain a predisposition to make these words synonymous doesn’t make it the right thing to do.

There’s even a contingent that insists that enterprise doesn’t just mean a commercial business organization, that it means a specific kind of commercial business organization, one that exceeds some critical threshold with respect to its scale, complexity, sophistication, ambition or consequence.  This is a bit like insisting that the implied “building” in “(building) architecture” means “commercial building”, or more specifically, “skyscraper.”

The problem with this concept of enterprise arises when one tries to specify the objective criteria by which one distinguishes a mere business from the bigger, more complex, more sophisticated, more ambitious or more consequential business that deserves to be called an enterprise.  It is certainly the case that the larger, more complex, more sophisticated, more ambitious and more consequential a commercial business organization is, the more likely architectural thinking will be necessary and beneficial.  But this observation about Enterprise Architecture does not mean that we ought to define enterprise to mean a large, complex, sophisticated, ambitious and consequential commercial business organization.

Why have so many naval vessels been named Enterprise?  Why was the Starship Enterprise from the Star Trek franchise so named, and why was this thought to be an appropriate name for the first space shuttle?  It was not because these vessels embodied some idea of a commercial business organization or because the word connoted a big, complex, sophisticated, ambitious or consequential business.  And surely if the latter had been the reason, there would be many lesser vessels named simply “Business”?

There are two significant consequences to basing Enterprise Architecture (EA) on a concept of enterprise that is limited to a particular kind of organization.  The first has to do with the applicability of the discipline, and the second has to do with how we educate enterprise architects.

If we restrict the definition of enterprise to a specific kind of purposeful activity, whether the criteria we use for this restriction are subjective or objective, we must either argue that architectural thinking is inapplicable to those purposeful activities that do not satisfy these restrictions, or we have to find a word to denote the larger class of purposeful activities to which architectural thinking applies, a class that includes both the restricted concept of enterprise and all other activities to which architectural thinking applies.

If enterprise means the same thing as commercial business organization, what do we call an entity that is not a commercial business organization (e.g., a church, a hospital, a government, or an army)?  Does Enterprise Architecture not apply to such endeavors because they are not created primarily to conduct business transactions?  What do we call organizations that are not businesses?  If we want to talk about an organization that is a business, why can’t we just use the compound “business organization”, which not only does not erase the distinction, it makes clear the relationship between the two?  Similarly, if we want to talk about an enterprise that is a business, as an enterprise, why can’t we just use the compound “business enterprise”?

Similarly, what should we call the architectural discipline that applies to human enterprise in general, and of which any more narrowly defined concept of Enterprise Architecture is necessarily a specialization?

Expanding definitions

The recent surge of interest in “Business Architecture” is, in my opinion, reflective of both the realization by the community that the historically IT-centric focus of Enterprise Architecture is unnecessarily circumscribed, and the lack of a systematic and internally consistent concept of Enterprise Architecture shared throughout that community.

There is a growing faction within the EA community that argues that most of Enterprise Architecture as practiced is actually enterprise IT architecture (EITA), and calling this practice EA is a misuse of the term.  Despite this, the widespread adoption of the egregiously oversimplified model of an enterprise as comprising “the business” and IT, and thus, Enterprise Architecture as comprising “Business Architecture” and “IT Architecture”, has led to the emergence of “Business Architecture” as a distinct if ill-defined concept.

It seems to me that many people consider Enterprise Architecture to be so hopelessly tainted by its historic IT-centricity that they view the best course to be allowing Enterprise Architecture to continue to be misused to mean EITA, and letting Business Architecture take its place as what EA “should have meant.”  I note in passing that there are some people who insist that EA “has always meant,” or at least “originally” meant, the architecture of the enterprise as a whole, but was hijacked by the IT community, though no one has been able to provide other than thirty year old recollections to support this assertion.

As I noted at the outset, I think Enterprise Architecture should encompass the application of architectural thinking to human endeavors of all kinds, not just those that are primarily business in nature, including, for example, governmental, military, religious, academic, or medical enterprises.  Yes, these endeavors all have some business aspects, but they are not what we normally call businesses, and calling the discipline “Business Architecture” almost unavoidably encourages us to overlook the architectural needs of such non-business-centric endeavors and focus instead on the needs of one specific kind of endeavor.

We have the words to name these things properly. We simply have to start doing so.

In part 3 of this series, I’ll consider the implications of a more inclusive concept of enterprise on the future of Enterprise Architecture.

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

2 Comments

Filed under Business Architecture, Enterprise Architecture

Different Words Mean Different Things, Part 1

By Leonard Fehskens, The Open Group

Over on the LinkedIn Enterprise Architecture Network discussion group there is a thread on the relationship between Enterprise Architecture (EA) and Business Architecture that as of late November 2012 had run to over 4100 comments.

Some of the sprawl of this thread is due to the usual lack of discipline in staying on topic.  Some of it is due to the rehashing of well-worn themes as newcomers arrive.  It seems clear to me though, that even when long time contributors try to move the subject forward, a lot of the back and forth that fails to converge is a consequence of the community’s lack of an appropriate and widely shared vocabulary.

In particular, there are four words that many in the Enterprise and Business Architecture communities seem to use interchangeably – enterprise, business, organization and corporation.

Before I tackle this subject, there is some context I should provide.

First, people who know me consider me to be obsessive about the precise use of language, and they’re right.  I think of Enterprise Architecture as more a craft than a science, and as such, the language we use to express it is ordinary language (as opposed to, for example, mathematics).  To me it follows that it is especially important that we use that language carefully.

Second, I’m coming at this from the perspective of creating a profession and its supporting ecosystem.  I believe a profession should be broadly applicable, with specializations within the profession addressing more narrowly focused concerns.

Finally, though much of the discussion about Enterprise Architecture is in English, I acknowledge that for a large fraction of the community English is a second (or third) language.  So, while this post is specifically about English usage, I suspect much of it applies as well to other languages, and I don’t want to imply that the conventions of English usage are the only ones worthy of consideration.

That’s enough by way of preamble.

The EA community may not have agreed upon definitions of many of the words it uses, but as these words are drawn from the vernacular, the rest of the world does.  This conventional usage makes clear distinctions between enterprise, business, organization and corporation.

While it is true that these words all have some sense in which they are roughly synonymous, they have primary definitions that distinguish them from one another.  I think we ought to observe these distinctions because they are useful, especially in that they allow us to sensibly relate the concepts they represent to one another, and they do not needlessly foreclose the broader application of these concepts.

First, I’m going to propose definitions for these words to be used in the context of Enterprise Architecture.  Then I’m going to look at what these definitions imply about the relationships between the things these words denote, and how the current usage obscures or denies these relationships.

It’s very possible, if not likely, that you will not agree with these definitions.  I’ll deal with that later.

Enterprise

The Oxford English Dictionary (Compact Edition, 1971) defines “enterprise” as:

Derived from the French entreprendre, “to take in hand, undertake”.

    1. A design of which the execution is attempted; a piece of work taken in hand, an undertaking; chiefly, and now exclusively, a bold, arduous, or momentous undertaking.
      • b. engagement in such undertaking
    2. Disposition or readiness to engage in undertakings of difficulty, risk, or danger; daring spirit.
    3. The action of taking in hand; management, superintendence. Obsolete.

So, enterprise means “undertaking” or “endeavor,” especially one that is relatively ambitious.  Implicit in this concept of enterprise is the intentional action of one of more people.  It is intentional in the sense that the action is intended to achieve some outcome.  The role of people is important; we do not generally consider machines, regardless of their purpose, to exhibit “enterprise” in this sense.  For me, the essential properties of an enterprise are people and their activity in pursuit of explicit intent.

This is a deliberately, very broadly inclusive concept of enterprise.  All of the following are, in my opinion, enterprises:

  • A child’s lemonade stand
  • A club
  • A professional society
  • A committee or working group
  • A town, state or country government
  • An international/multinational coalition
  • A military unit
  • A department or ministry of defense
  • A for-profit, non-profit or not-for-profit corporation
  • A partnership
  • A consortium
  • A church
  • A university or college
  • A hospital

Business

English speakers commonly use the word “business” to mean three things, and are usually able to infer the intended meaning from context.  These three common meanings of business are:

Business-as-commerce: The exchange of goods and services for some form of compensation for the costs and risks of doing so.

Business-as-commercial-entity: An entity whose primary activity is the conduct of some form of business-as-commerce.  In colloquial terms, the primary purpose of such an entity is to “make money”, and if it does not “make money” it will “go out of business.”

Business-as-primary-concern: The primary concern or activity of some entity.

These three different commonly understood meanings of business make it possible for someone to say something like:

“The business of my business is business.”

I.e., “The business-as-primary-concern of my business-as-commercial-entity is business-as-commerce.”

Organization

An “organization” is a structured (i.e., “organized”) group of people and resources, usually acting in concert to achieve some shared purpose.

Corporation

Finally, a “corporation” is an organization structured and operated in a particular way so as to satisfy certain legal constraints and thus benefit from the legal consequences of that conformance.  Strictly speaking, a corporation is a legal entity that has an organization associated with it.  In the case of a “shell” or “dummy” corporation, the associated organization’s people and resources may be minimal.

Observations

Based on these definitions, one can make some observations.

An organization is typically the means by which an enterprise is realized.  Small scale enterprises may be realized by a single individual, which is a trivial case of an organization.

Not all organizations are business-as-commercial-entities.  Organizations that are not businesses will almost certainly conduct some business-as-commerce as an adjunct activity in support of their primary intent.

Not all enterprises have as their intent some form of business-as-commerce. An organization that realizes such an enterprise will not be a business-as-commercial-entity.  While all business-as-commercial-entities realize an enterprise, not all enterprises are realized by business-as-commercial-entities.

Not all organizations are corporations.

Not all business-as-commercial-entities are corporations.

These relationships are depicted below.

 Len diagram

This is a three-part series that discusses how our vocabulary affects the way we conceptualize Enterprise Architecture, Business Architecture and their relationship.  Part 2 will examine the effect of our definition of enterprise on how we think about EA. 

 Len Fehskens is Vice President of Skills and Capabilities at The Open GroupHe is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. He majored in Computer Science at MIT, and has over 40 years of experience in the IT business as both an individual contributor and a manager, within both product engineering and services business units. Len has worked for Digital Equipment Corporation, Data General Corporation, Prime Computer, Compaq and Hewlett Packard.  He is the lead inventor on six software patents on the object oriented management of distributed systems.

5 Comments

Filed under Business Architecture, Enterprise Architecture

ArchiMate® 2.0 and Beyond

By The Open Group Conference Team

In this video, Henry Franken of BiZZdesign discusses ArchiMate® 2.0, the new version of the graphical modeling language for Enterprise Architecture that provides businesses with the means to communicate with different stakeholders from the business goals level to implementation scenarios.

Franken explains that the first edition allowed users to express Enterprise Architecture at its core – modeling business applications and infrastructure. ArchiMate® 2.0 has two major additions to make it fully aligned with TOGAF® – the motivation extension and the migration and planning extension. The motivation extension provides users with the ability to fully express business motivations and goals to enterprise architects; the migration and planning extension helps lay out programs and projects to make a business transition.

There are several sessions on ArchiMate® at the upcoming Open Group Conference in Barcelona. Notably, Henry Franken’s “Delivering Enterprise Architecture with TOGAF® and ArchiMate®” session on October 22 at 2:00-2:45 p.m. UTC / 8:00-8:45 a.m. EST will be livestreamed on The Open Group Website.

To view these sessions and for more information on the conference, please go to: http://www3.opengroup.org/barcelona2012

Comments Off

Filed under ArchiMate®, Conference, Enterprise Architecture

Five Types of Bad Chief Architect Characters – We Have The Whole List!

By Håkan Edvinsson and Peter Tallungs

We have looked at some of the extreme personality types of chief architects to provide some hints on how to deal with them. Below is a list of five Enterprise Architecture characters we have unfortunately encountered in the real world with a few tips on how these characters can be managed.

The Technical Solution Architect

Is this the chief technology officer (CTO) with a title change? The technical solution architect is the CTO with the eternal technology focus. This person is no more interested in information quality stored in the systems, than a plumber on a shunt-conference is interested in challenges around clean fresh water.

Risk: The business needs are not met. Too many repetitions of the development projects since the last (untested) tool should preferably be used.

Strategy: Make sure to get the debate on business value for each new initiative. Go with the client on the most critical business needs to be resolved with risk-free methods and techniques. Clarify what is “good-enough” and go no further, but also accept that experimentation workshops are needed.

The Choleric

“The important thing is not the results, it is listening to me. Debate is a competition and that I win is more important than your content is right. We are a team that I lead and my PowerPoint slides rule.” The Choleric has zero tolerance for criticism –they may very well have a background in sports.

Risk: Creativity is hampered and initiatives are slowed down.

Strategy: This person is probably good as a manager in a highly competitive situation, but perhaps not in architecture. The architects who succeed around the Choleric can be forced to develop two personalities: one who likes certainty and swallows pride to survive in the architecture team, and the other that does what is needed and constantly has to think about accountability.

Is this situation too hard? Change the job to not go under.

The Flying High

The Flying High architect might give the impression of being a philosophical and thoughtful. It takes time to any get response at all from this person. But it is a person who very well may take in lots of information and the bookshelves are filled with the great thinkers. When an answer finally arrives it hits a bit above most people’s heads. Critics do not bite.

Risk: Can kill the architectural concept of the organization because it is difficult to understand and does not lead to anything.

Strategy: Be the complementary pragmatics. Search for any practical use in the high flying ideas – there is almost always something useful that you can become an interpreter of. Even in a bushy framework there are treasures that can form principles for daily work.

The Detailer

The Detailer is considered to be on the safe side of the organization and at least one manager away from the CIO. This person wants solutions to be almost perfect –they see detailed obstacles, take criticism personally and this person is invaluable in the right contexts – such are unfortunately rare.

Risk: Architecture work slows rather than enables. The architects are constantly rounded because they are just awkward.

Strategy: The trick is to get a detailer in the right context to make clear its core issue there because there are sometimes matters of detail which are the most essential. The detailer should normally not be prolonged as chief architect.

The solution for this person is to get a specialized role where it really requires going to the bottom. The solution for you is to become the complement working on a higher level of abstraction and work with the possibilities.
The Methodist

The Methodist is the architect that is completely sold on everything that the method he/she has been certified in. The method is quite adequate, sufficient and suited for any application. Can always respond to criticism of the method – any other criticism falls on the side.

Risk: The stakeholder stop listening because everyone knows what the answer will be – what the method says.

Strategy: Do not participate in the method debate. Instead stretch the limits of this universal method, and do what is needed.

What type are you?

Are you the same as any of the above types? If you are, then you probably do not have a problem with just her or him – but maybe with all the other people around you.

Common to these types is that they are not on the job for the right reasons. Probably it’s mostly about themselves and their own interests even if they do not realize it themselves.

It is easy to note that there are good and bad leaders in all professions. Architects not exempt from it. The problems arise when the Enterprise Architecture is questioned and will put it in connection with the chief architect’s personality. It becomes the brand of the Enterprise Architecture.

Your best choice is to get a clear personal brand in your organization and to provide a better alternative than the above types –perhaps in line with the more desirable chief architect.

The Desirable

The Desirable is an architect that does not use a method from book, but rather calls on common sense and experience. For example, reasoning that “the projects we have planned over the next year will face the same problem. Let us deal with it first and hand over that platform to the projects. They do, after all, do not want to focus on that. Then we ensure that what is common will not fall through the cracks, or the wrong seat.”

Reward: The desirable is pragmatic while simultaneously setting his sights high. Recognizes sensible criticism, listen and trust the members of the architectural team.

Written by Håkan Edvinsson and Peter Tallungs

Translated and adapted by Mats Gejnevall

Originally published on trendspaning.se 

4 Comments

Filed under Enterprise Architecture

TOGAF® and BIAN – A strong proposition for the Banking Industry

By Thomas Obitz, KPMG

Earlier this year, a working group led by Paul Bonnie, ING and I published a white paper on the integration of TOGAF® and BIAN, the framework of the Banking Industry Architecture Network. Gartner even suggested that the white paper greatly aids the big problem of arriving at a consistent reference model for banks. So how does a white paper help practicing architects in banks?

Every enterprise architect knows the two most difficult questions in a complex transformation initiative: How to describe the architecture of an organization – how to break down its functions and services, and arrive at a model which makes sense to everybody; and where to get started – what needs to be done, and how do the outputs fit together?

For this second question, the industry has pretty much agreed on the answer – TOGAF. It is a best practice process with a tremendous acceptance in the market place. However, it is industry independent, and, therefore, will not provide any models describing the specifics of a bank, or even the banking IT landscape. This gap of vertical content is a significant hurdle when attempting to get architecture initiatives off the ground.

Looking at our options within The Open Group Architecture Forum to address this challenge, creating industry-specific variants of the TOGAF framework would have stretched resources a bit too thin – and so the Architecture Forum decided to find a partner to collaborate with. We found it in BIAN.

BIAN, the Banking Industry Architecture Network, publishes a reference model for the services required as building blocks in the IT landscape of a bank. Like TOGAF, it leverages the experience of its members to identify best practices, and it has the support of major banks, leading software vendors and consultancies. The current services landscape has reached a certain level of maturity, describing more than 250 services.

The white paper describes how TOGAF and BIAN fit together, and where and how to use the BIAN collateral. Adapting the frameworks together yields several key benefits:

  • The services landscape provides architects with a canvas to structure the IT landscape, to map their inherent challenges, and scope solutions quickly. Hence, it speeds up activities in the time critical mobilization phase of a transformation initiative and helps to keep momentum.
  • Once a solution has been scoped in alignment with the services landscape, vendors supporting the BIAN reference model can provide components that implement the services. Consequently, it helps in the process of vendor selection.
  • As the responsibilities of components and the business objects exchanged between them are defined, integration between components of the landscape becomes much easier, reducing integration cost and complexity.

In a recent engagement with a retail bank, I used the services landscape as the starting point for the analysis of the challenges the bank was facing and to map out potential solutions. It allowed the team to start out quickly with a structure that was accepted and natural.

So when you are looking for an approach to making a large transformation initiative fly – have a look at our paper, and use it as a tool for making your life easier. And please do give us feedback on your experiences with it via email or in the comments section of this blog post.


Thomas Obitz is a Principal Advisor with KPMG LLP in London. Building on more than 20 years of experience in the IT industry, he acts primarily as a lead architect of major initiatives, as an enterprise architect, and a business architect. He has more than 13 years of experience in the Financial Services industry, with a strong focus on Investment Banking and Capital Markets. 

1 Comment

Filed under Business Architecture, TOGAF®

ArchiMate 2.0 – Ready for the Future of Enterprise Architecture!

By Henry Franken, BIZZdesign

Models have played an important role in business for a long time. Process models, information- and data models, application landscapes, strategic models, operational models – you name it, organizations have tried it. With the rise of Enterprise Architecture (EA) as a strategic discipline for many organizations, we saw two interesting developments. First of all, organizations try to connect their models, to gain insight in the way the enterprise works from many different perspectives. Secondly, we saw the trend that models become more high-level, focusing on the essence of the organization.

These developments have led to the development of the ArchiMate® language, which allows high-level modeling within a domain, but allows modeling the relations between domains. Even more, in recognition that architecture is a communications game, a key driver for the language was to also allow for effective visualizations for key stakeholders based on solid architectural analyses.

The first edition of the ArchiMate language enabled organizations to create holistic architecture models with concepts from three domains: business, application and technology. With a handful of concepts and relations, this allowed organizations to model the relation between products and services, processes, supporting applications and information, as well as infrastructure. Having modeled this formally, organizations can do impact assessments, generate visualizations for various stakeholders and so on.

ArchiMate has recently been extended by members within the ArchiMate Forum within The Open Group), resulting in ArchiMate 2.0 – a new version of ArchiMate that is fully aligned with The Open Group Architecture Framework (TOGAF®). Two new extensions have been developed for this purpose, making sure the language now covers the entire Architecture Development Method (ADM) of TOGAF.

The new motivation extension allows organizations to graphically model the answer to the “why” question of EA: Who are key stakeholders of EA? What are their drivers? How do these drivers lead to principles and requirements that are realized in the architecture? This extension mainly aligns with the early phases of the TOGAF ADM.

The new ArchiMate 2.0 standard also has an implementation and migration extension that aligns with the later phases of the ADM. Using this extension, architects can align with project management and graphically model plateaus, projects and programs, as well as their deliverables.

One of the key strengths of ArchiMate – as well as TOGAF – is its openness – it allows practitioners worldwide to join in and help push the language forward. Indeed, we are seeing the adoption of the language, as well as certifications of practitioners grow worldwide.

The Open Group has introduced certification programs for individuals, training vendors and tool vendors, and the uptake of these programs is very successful! We are now seeing many individuals obtaining an ArchiMate 2.0 certificate, training vendors applying for training accreditation, and tool vendors implementing the ArchiMate modeling language into Enterprise Architecture modeling tools, all while  being certified by The Open Group.

With all these great developments within the last few years – fluent integration with TOGAF and a fast growing number of professionals using ArchiMate – I believe it is safe to say that with ArchiMate 2.0 you are ready for the future of Enterprise Architecture!

Henry Franken is the managing director of BiZZdesign and is chair of The Open Group ArchiMate Forum. As chair of The Open Group ArchiMate Forum, Henry led the development of the ArchiMate Version 2.o standard. Henry is a speaker at many conferences and has co-authored several international publications and Open Group White Papers. Henry is co-founder of the BPM-Forum. At BiZZdesign, Henry is responsible for research and innovation.

4 Comments

Filed under ArchiMate®, Certifications, Enterprise Architecture, Enterprise Transformation, TOGAF®

Video Highlights Day 2 of Washington, D.C.

By The Open Group Conference Team

How can you use the tools of Enterprise Architecture and open standards to improve the capability of your company doing business? The Day 2 speakers of The Open Group Conference in Washington, D.C. addressed this question, focusing on Enterprise Transformation. Sessions included:

  • “Case Study: University Health Network (Toronto),” by Jason Uppal, chief enterprise architect at QR Systems, Inc. and winner of the 2012 Edison Award for Innovation
  • “Future Airborne Capability Environment (FACE™): Transforming the DoD Avionics Software Industry Through the Use of Open Standards,” by Judy Cerenzia, FACE™ program director at The Open Group, Kirk Avery, chief software architect at Lockheed Martin and Philip Minor, director at System of Systems of Engineering Directorate at the Office of Chief Systems Engineer, ASA(ALT)
  • “Using the TOGAF® Architecture Content Framework with the ArchiMate® Modeling Language,” by Henry Franken, CEO of BIZZdesign, and Iver Band, enterprise architect at Standard Insurance

David Lounsbury, CTO of The Open Group summarizes some of the day’s sessions:

Comments Off

Filed under ArchiMate®, Business Architecture, Certifications, Conference, Cybersecurity, Enterprise Architecture, Enterprise Transformation, FACE™, Information security, TOGAF®, Uncategorized

Apple Registers Mac OS X 10.8 Mountain Lion to the UNIX® 03 Standard

By Andrew Josey, The Open Group

Today, Apple, Inc. released the latest version of the Mac OS X, version 10.8, also known as “Mountain Lion.” In addition to the product’s release, we are pleased to announce that Mac OS X Mountain Lion has achieved certification to The Open Group UNIX® 03 standard, which is the mark for systems conforming to the Single UNIX Specification, Version 3.

The Single UNIX Specification is an open specification that defines the set of required interfaces for a conformant UNIX system. Support for the Single UNIX Specification permits wide portability of applications between compliant and compatible operating systems. High reliability, availability and scalability are all attributes associated with certified UNIX® systems. By registering operating systems as compliant with the Single UNIX Specification, UNIX system suppliers assure their users of the stability, application portability and interoperability of their products.

Over the years, Apple has been a great supporter of the UNIX standard, and today, Mac OS X is the most widely used UNIX desktop operating system. Apple’s installed base—over 50 million users— and commitment to the UNIX standard as a platform is significant to the UNIX certification program. We look forward to continuing to work with Apple and our other UNIX partners in promoting open and interoperable operating systems as the specification continues to evolve.

Andrew Josey is Director of Standards within The Open Group. He is currently managing the standards process for The Open Group, and has recently led the standards development projects for TOGAF 9.1, ArchiMate 2.0, IEEE Std 1003.1-2008 (POSIX), and the core specifications of the Single UNIX Specification, Version 4. Previously, he has led the development and operation of many of The Open Group certification development projects, including industry-wide certification programs for the UNIX system, the Linux Standard Base, TOGAF, and IEEE POSIX. He is a member of the IEEE, USENIX, UKUUG, and the Association of Enterprise Architects.

Comments Off

Filed under Certifications, Standards, UNIX

Summer in the Capitol – Looking Back at The Open Group Conference in Washington, D.C.

By Jim Hietala, The Open Group

This past week in Washington D.C., The Open Group held our Q3 conference. The theme for the event was “Cybersecurity – Defend Critical Assets and Secure the Global Supply Chain,” and the conference featured a number of thought-provoking speakers and presentations.

Cybersecurity is at a critical juncture, and conference speakers highlighted the threat and attack reality and described industry efforts to move forward in important areas. The conference also featured a new capability, as several of the events were Livestreamed to the Internet.

For those who did not make the event, here’s a summary of a few of the key presentations, as well as what The Open Group is doing in these areas.

Joel Brenner, attorney with Cooley, was our first keynote. Joel’s presentation was titled, “Turning Us Inside-Out: Crime and Economic Espionage on our Networks,” The talk mirrored his recent book, “America the Vulnerable: Inside the New Threat Matrix of Digital Espionage, Crime, and Warfare,” and Joel talked about current threats to critical infrastructure, attack trends and challenges in securing information. Joel’s presentation was a wakeup call to the very real issues of IP theft and identity theft. Beyond describing the threat and attack landscape, Joel discussed some of the management challenges related to ownership of the problem, namely that the different stakeholders in addressing cybersecurity in companies, including legal, technical, management and HR, all tend to think that this is someone else’s problem. Joel stated the need for policy spanning the entire organization to fully address the problem.

Kristin Baldwin, principal deputy, systems engineering, Office of the Assistant Secretary of Defense, Research and Engineering, described the U.S. Department of Defense (DoD) trusted defense systems strategy and challenges, including requirements to secure their multi-tiered supply chain. She also talked about how the acquisition landscape has changed over the past few years. In addition, for all programs the DoD now requires the creation of a program protection plan, which is the single focal point for security activities on the program. Kristin’s takeaways included needing a holistic approach to security, focusing attention on the threat, and avoiding risk exposure from gaps and seams. DoD’s Trusted Defense Systems Strategy provides an overarching framework for trusted systems. Stakeholder integration with acquisition, intelligence, engineering, industry and research communities is key to success. Systems engineering brings these stakeholders, risk trades, policy and design decisions together. Kristin also stressed the importance of informing leadership early and providing programs with risk-based options.

Dr. Ron Ross of NIST presented a perfect storm of proliferation of information systems and networks, increasing sophistication of threat, resulting in an increasing number of penetrations of information systems in the public and private sectors potentially affecting security and privacy. He proposed a need an integrated project team approach to information security. Dr. Ross also provided an overview of the changes coming in NIST SP 800-53, version 4, which is presently available in draft form. He also advocated a dual protection strategy approach involving traditional controls at network perimeters that assumes attackers outside of organizational networks, as well as agile defenses, are already inside the perimeter. The objective of agile defenses is to enable operation while under attack and to minimize response times to ongoing attacks. This new approach mirrors thinking from the Jericho Forum and others on de-perimeterization and security and is very welcome.

The Open Group Trusted Technology Forum provided a panel discussion on supply chain security issues and the approach that the forum is taking towards addressing issues relating to taint and counterfeit in products. The panel included Andras Szakal of IBM, Edna Conway of Cisco and Dan Reddy of EMC, as well as Dave Lounsbury, CTO of The Open Group. OTTF continues to make great progress in the area of supply chain security, having published a snapshot of the Open Trusted Technology Provider Framework, working to create a conformance program, and in working to harmonize with other standards activities.

Dave Hornford, partner at Conexiam and chair of The Open Group Architecture Forum, provided a thought provoking presentation titled, “Secure Business Architecture, or just Security Architecture?” Dave’s talk described the problems in approaches that are purely focused on securing against threats and brought forth the idea that focusing on secure business architecture was a better methodology for ensuring that stakeholders had visibility into risks and benefits.

Geoff Besko, CEO of Seccuris and co-leader of the security integration project for the next version of TOGAF®, delivered a presentation that looked at risk from a positive and negative view. He recognized that senior management frequently have a view of risk embracing as taking risk with am eye on business gains if revenue/market share/profitability, while security practitioners tend to focus on risk as something that is to be mitigated. Finding common ground is key here.

Katie Lewin, who is responsible for the GSA FedRAMP program, provided an overview of the program, and how it is helping raise the bar for federal agency use of secure Cloud Computing.

The conference also featured a workshop on security automation, which featured presentations on a number of standards efforts in this area, including on SCAP, O-ACEML from The Open Group, MILE, NEA, AVOS and SACM. One conclusion from the workshop was that there’s presently a gap and a need for a higher level security automation architecture encompassing the many lower level protocols and standards that exist in the security automation area.

In addition to the public conference, a number of forums of The Open Group met in working sessions to advance their work in the Capitol. These included:

All in all, the conference clarified the magnitude of the cybersecurity threat, and the importance of initiatives from The Open Group and elsewhere to make progress on real solutions.

Join us at our next conference in Barcelona on October 22-25!

Jim Hietala, CISSP, GSEC, is the Vice President, Security for The Open Group, where he manages all IT security and risk management programs and standards activities. He participates in the SANS Analyst/Expert program and has also published numerous articles on information security, risk management, and compliance topics in publications including The ISSA Journal, Bank Accounting & Finance, Risk Factor, SC Magazine, and others.

Comments Off

Filed under Conference, Cybersecurity, Enterprise Architecture, Information security, OTTF, Security Architecture, Supply chain risk, TOGAF®

TOGAF® 9 Certification Growth – Number of Individuals Certified Doubles in the Last 12 Months – Now Over 14,800

By Andrew Josey, The Open Group

The number of individuals certified in the TOGAF® 9 certification program as of July 1st 2012 is 14,851. This represents a doubling of the number of individuals certified in the last 12 months with 7,640 new certifications during that period. The latest statistics show that certifications are now growing at two thousand individuals per quarter.

TOGAF is being adopted globally. The top five countries include the UK, Netherlands, USA, Australia and India.

Here is a list of individuals certifications among the top 20 countries, as of July 2012

Rank # Individuals Country Percentage
1 2444 UK 16.2
2 1916 USA 12.8
3 1607 Netherlands 10.8
4 1093 Australia 7.3
5 913 India 6.1
6 705 Canada 4.7
7 637 South Africa 4.2
8 524 Finland 3.5
9 517 France 3.4
10 434 China 2.8
11 379 Norway 2.5%
12 344 Sweden 2.3%
13 280 Germany 1.8%
14 271 Belgium 1.8%
15 244 United Arab Emirates 1.6%
16 224 Denmark 1.5%
17 209 Japan 1.4%
18 176 New Zealand 1.1%
19 173 Saudi Arabia 1.1%
20 136 Czech Republic 0.9%

There are 43 TOGAF 9 training partners worldwide and 48 accredited TOGAF 9 courses.  More information on TOGAF 9 Certification, including the official accredited training course calendar and a directory of certified people and, can be found on The Open Group website at: http://www.opengroup.org/togaf9/cert/.

(This blog post was edited on August 16)

Andrew Josey is Director of Standards within The Open Group. He is currently managing the standards process for The Open Group, and has recently led the standards development projects for TOGAF 9.1, ArchiMate 2.0, IEEE Std 1003.1-2008 (POSIX), and the core specifications of the Single UNIX Specification, Version 4. Previously, he has led the development and operation of many of The Open Group certification development projects, including industry-wide certification programs for the UNIX system, the Linux Standard Base, TOGAF, and IEEE POSIX. He is a member of the IEEE, USENIX, UKUUG, and the Association of Enterprise Architects.

14 Comments

Filed under Certifications, Enterprise Architecture, TOGAF®

ArchiMate at the Washington, D.C. Conference #ogDCA

By Iver Band, Standard Insurance Company

The Open Group offers many opportunities to learn about ArchiMate®, the fast-growing visual modeling language standard for Enterprise Architecture. ArchiMate enables enterprise architects to develop rich and clear graphical representations that are accessible to a wide range of stakeholders while providing clear direction to downstream architects and designers. Looking forward to this week’s Washington, D.C. conference, let’s examine the various sessions where attendees can learn more about this modeling language standard.

On Sunday, July 15, start with the ArchiMate 2.0 pre-conference introductory session from 4:30-5:00 p.m. ET led by BiZZdesign CEO and ArchiMate Forum Chair Henry Franken. Right afterward, from 5:00-5:30 ET, learn about ArchiMate certification along with other certifications offered by The Open Group.  Conference attendees can engage further with the language at one of the interactive Learning Lab sessions from 5:30-6:15 p.m. ET.

On Tuesday, July 17, learn how to use the ArchiMate language for architecture projects based on TOGAF®.  From 11:30-12:45 p.m. ET, I will join Henry, and together, we will present an in-depth tutorial on “Using the TOGAF Architecture Content Framework with the ArchiMate Modeling Language.” From 2:00-2:45 p.m. ET,  I will explore how to use ArchiMate to shed light on the complex interplay between people and organizations, and their often conflicting challenges, principles, goals and concerns.  My presentation “Modeling the Backstory with ArchiMate 2.0 Motivation Extension” will demonstrate this approach with a case study on improving customer service. Then, from 2:45-3:30 p.m. ET, The Business Forge Principal Neil Levette will present the session “Using the ArchiMate Standard as Tools for Modeling the Business.” Neil will explain how to use the ArchiMate language with Archi, a free tool, to model key business management mechanisms and the relationships between business motivations and operations. Finally, from 4:00-5:30 p.m. ET, Henry and I will join the “Ask the Experts: TOGAF and ArchiMate” panel to address conference attendee and Open Group member questions.

Don’t miss these opportunities to learn more about this powerful standard!

Iver Band is the vice chair of The Open Group ArchiMate Forum and is an enterprise architect at Standard Insurance Company in Portland, Oregon. Iver chose the TOGAF and ArchiMate standards for his IT organization and applies them enthusiastically to his daily responsibilities. He co-developed the initial examination content for the ArchiMate 2 Certification for People  and made other contributions to the ArchiMate 2 standard. He is TOGAF 9 Certified,  ArchiMate 2 Certified and a Certified Information Systems Security Professional.

Comments Off

Filed under ArchiMate®, Conference, Enterprise Architecture

Leveraging TOGAF to Deliver DoDAF Capabilities

By Chris Armstrong, Armstrong Process Group

In today’s environment of competing priorities and constrained resources, companies and government agencies are in even greater need to understand how to balance those priorities, leverage existing investments and align their critical resources to realize their business strategy. Sound appealing? It turns out that this is the fundamental goal of establishing an Enterprise Architecture (EA) capability. In fact, we have seen some of our clients position EA as the Enterprise Decision Support capability – that is, providing an architecture-grounded, fact-based approach to making business and IT decisions.

Many government agencies and contractors have been playing the EA game for some time — often in the context of mandatory compliance with architecture frameworks, such as the Federal Enterprise Architecture (FEA) and the Department of Defense Architecture Framework (DoDAF). These frameworks often focus significantly on taxonomies and reference models that organizations are required to use when describing their current state and their vision of a future state. We’re seeing a new breed of organizations that are looking past contractual compliance and want to exploit the business transformation dimension of EA.

In the Department of Defense (DoD) world, this is in part due to the new “capability driven” aspect of DoDAF version 2.0, where an organization aligns its architecture to a set of capabilities that are relevant to its mission. The addition of the Capability Viewpoint (CV) in DoDAF 2 enables organizations to describe their capability requirements and how their organization supports and delivers those capabilities. The CV also provides models for representing capability gaps and how new capabilities are going to be deployed over time and managed in the context of an overall capability portfolio.

Another critical difference in DoDAF 2 is the principle of “fit-for-purpose,” which allows organizations to select which architecture viewpoints and models to develop based on mission/program requirements and organizational context. One fundamental consequence of this is that an organization is no longer required to create all the models for each DoDAF viewpoint. They are to select the models and viewpoints that are relevant to developing and deploying their new, evolved capabilities.

While DoDAF 2 does provide some brief guidance on how to build architecture descriptions and subsequently leverage them for capability deployment and management, many organizations are seeking a more well-defined set of techniques and methods based on industry standard best practices.

This is where the effectiveness of DoDAF 2 can be significantly enhanced by integrating it with The Open Group Architecture Framework (TOGAF®) version 9.1, in particular the TOGAF Architecture Development Method (ADM). The ADM not only describes how to develop descriptions of the baseline and target architectures, but also provides considerable guidance on how to establish an EA capability and performing architecture roadmapping and migration planning. Most important, the TOGAF ADM describes how to drive the realization of the target architecture through integration with the systems engineering and solution delivery lifecycles. Lastly, TOGAF describes how to sustain an EA capability through the operation of a governance framework to manage the evolution of the architecture. In a nutshell, DoDAF 2 provides a common vocabulary for architecture content, while TOGAF provides a common vocabulary for developing and using that content.

I hope that those of you in the Washington, D.C. area will join me at The Open Group conference next week, where we’ll continue the discussion of how to deliver DoDAF capabilities using TOGAF. For those of you who can’t make it, I’m pleased to announce that The Open Group will also be delivering a Livestream of my presentation (free of charge) on Monday, July 16 at 2:45 p.m. ET.

Hope to see you there!

Chris Armstrong, president of Armstrong Process Group, Inc., is an internationally recognized thought leader in Enterprise Architecture, formal modeling, process improvement, systems and software engineering, requirements management, and iterative and agile development. Chris represents APG at The Open Group, the Object Management Group and the Eclipse Foundation.

 

2 Comments

Filed under Conference, Enterprise Architecture, TOGAF®

Adapting to an eBook World

By Chris Harding, The Open Group

Have you ever wanted to read something to prepare for a meeting while traveling, but  been frustrated by the difficulty of managing paper or a bulky PC? Travelers who read for pleasure have found eBooks a very convenient way to meet their needs. This format is now becoming available for select Open Group standards and guides, so that you can read them more easily when “on the road.”

The eBook format allows the device to lay out the text, rather than trying to fit pre-formatted pages to devices of all shapes and size (It is based on HTML). This makes reading an eBook a much easier and more pleasant experience than trying to read a static format such as PDF on a device where the page doesn’t fit.

There are portable electronic devices designed primarily for the purpose of reading digital books – the Amazon Kindle is the best known – but eBooks can also be read on tablets, mobile phones (on which the quality can be surprisingly good) and, of course, on laptops, using free-to-download software apps. The eBook readers are, essentially, small-sized special-purpose tablets with superb text display quality and – a big advantage on a long flight – batteries that can go weeks rather than hours without re-charging. As the quality and battery life of tablets continues to improve, they are starting to overtake specialized reader devices, which have one major disadvantage: a lack of standardization.

There are a number of different eBook formats, the most prominent being EPUB, an open standard created by the International Digital Publishing Forum, KF8, the proprietary format used by Amazon Kindle, and Mobipocket, a format that the Kindle will also handle (There is an excellent Wikipedia article on eBook formats, see http://en.wikipedia.org/wiki/Comparison_of_e-book_formats). You can read any of the most popular formats on a tablet (or PC, Mac, iPhone or Android device) using a software app, but you are likely to find that a specialized reader device is limited in the formats that it can handle.

Many of the Open Group SOA Standards and Guides are now freely available in the EPUB and Mobipocket formats from The Open Group bookstore. See http://soa-standards.opengroup.org/post/eBook-Versions-of-SOA-Standards-and-Guides-5884765 for the current list. We are hoping to make all our new SOA standards and guides available in this way, and also some Open Group publications on Cloud Computing. EPUB versions of TOGAF® Version 9.1, the TOGAF 9.1 Pocket Guide and the TOGAF 9 study guides are available for purchase from The Open Group’s official publisher, Van Haren. The SOA and the TOGAF EPUBS can be obtained from The Open Group bookstore at http://www.opengroup.org/bookstore/catalog .

Thirty years ago, I used to attend meetings of the CCITT (now the ITU-T) in Geneva. The trolleys that were pushed around the UN building, piled high with working documents for distribution to delegates, were an impressive sight, but the sheer weight of paper that had to be carried to and from the meetings was a real problem. Laptops with Internet access have removed the need to carry documents. Now, eBooks are making it easy to read them while traveling!

We have started to make eBook versions of our standards and guides available and are still exploring the possibilities. We’d love to hear your thoughts on what will or won’t work, and what will work best.  Please feel free to share your ideas in the comments section below.

Andrew Josey, director of standards at The Open Group, contributed to the technical aspects of this blog post. 

Dr. Chris Harding is Director for Interoperability and SOA at The Open Group. He has been with The Open Group for more than ten years, and is currently responsible for managing and supporting its work on interoperability, including SOA and interoperability aspects of Cloud Computing. He is a member of the BCS, the IEEE and the AEA, and is a certified TOGAF practitioner.

Comments Off

Filed under Cloud/SOA, TOGAF®

Learn How Enterprise Architects Can Better Relate TOGAF and DoDAF to Bring Best IT Practices to Defense Contracts

By Dana Gardner, Interarbor Solutions

This BriefingsDirect thought leadership interview comes in conjunction with The Open Group Conference in Washington, D.C., beginning July 16. The conference will focus on how Enterprise Architecture (EA), enterprise transformation, and securing global supply chains.

We’re joined by one of the main speakers at the July 16 conference, Chris Armstrong, President of Armstrong Process Group, to examine how governments in particular are using various frameworks to improve their architectural planning and IT implementations.

Armstrong is an internationally recognized thought leader in EA, formal modeling, process improvement, systems and software engineering, requirements management, and iterative and agile development.

He represents the Armstrong Process Group at the Open Group, the Object Management Group (OMG), and Eclipse Foundation. Armstrong also co-chairs The Open Group Architectural Framework (TOGAF®), and Model Driven Architecture (MDA) process modeling efforts, and also the TOGAF 9 Tool Certification program, all at The Open Group.

At the conference, Armstrong will examine the use of TOGAF 9 to deliver Department of Defense (DoD) Architecture Framework or DoDAF 2 capabilities. And in doing so, we’ll discuss how to use TOGAF architecture development methods to drive the development and use of DoDAF 2 architectures for delivering new mission and program capabilities. His presentation will also be Livestreamed free from The Open Group Conference. The full podcast can be found here.

Here are some excerpts:

Gardner: TOGAF and DoDAF, where have they been? Where are they going? And why do they need to relate to one another more these days?

Armstrong: TOGAF [forms] a set of essential components for establishing and operating an EA capability within an organization. And it contains three of the four key components of any EA.

First, the method by which EA work is done, including how it touches other life cycles within the organization and how it’s governed and managed. Then, there’s a skills framework that talks about the skills and experiences that the individual practitioners must have in order to participate in the EA work. Then, there’s a taxonomy framework that describes the semantics and form of the deliverables and the knowledge that the EA function is trying to manage.

One-stop shop

One of the great things that TOGAF has going for it is that, on the one hand, it’s designed to be a one-stop shop — namely providing everything that a end-user organization might need to establish an EA practice. But it does acknowledge that there are other components, predominantly in the various taxonomies and reference models, that various end-user organizations may want to substitute or augment.

It turns out that TOGAF has a nice synergy with other taxonomies, such as DoDAF, as it provides the backdrop for how to establish the overall EA capability, how to exploit it, and put it into practice to deliver new business capabilities.

Frameworks, such as DoDAF, focus predominantly on the taxonomy, mainly the kinds of things we’re keeping track of, the semantics relationships, and perhaps some formalism on how they’re structured. There’s a little bit of method guidance within DoDAF, but not a lot. So we see the marriage of the two as a natural synergy.

Gardner: So their complementary natures allows for more particulars on the defense side, but the overall TOGAF looks at the implementation method and skills for how this works best. Is this something new, or are we just learning to do it better?

Armstrong: I think we’re seeing the state of industry advance and looking at trying to have the federal government, both United States and abroad, embrace global industry standards for EA work. Historically, particularly in the US government, a lot of defense agencies and their contractors have often been focusing on a minimalistic compliance perspective with respect to DoDAF. In order to get paid for this work or be authorized to do this work, one of our requirements is we must produce DoDAF.

People are doing that because they’ve been commanded to do it. We’re seeing a new level of awareness. There’s some synergy with what’s going on in the DoDAF space, particularly as it relates to migrating from DoDAF 1.5 to DoDAF 2.

Agencies need some method and technique guidance on exactly how to come up with those particular viewpoints that are going to be most relevant, and how to exploit what DoDAF has to offer, in a way that advances the business as opposed to just solely being to conforming or compliant?

Gardner: Have there been hurdles, perhaps culturally, because of the landscape of these different companies and their inability to have that boundary-less interaction. What’s been the hurdle? What’s prevented this from being more beneficial at that higher level?

Armstrong: Probably overall organizational and practitioner maturity. There certainly are a lot of very skilled organizations and individuals out there. However, we’re trying to get them all lined up with the best practice for establishing an EA capability and then operating it and using it to a business strategic advantage, something that TOGAF defines very nicely and which the DoDAF taxonomy and work products hold in very effectively.

Gardner: Help me understand, Chris. Is this discussion that you’ll be delivering on July 16 primarily for TOGAF people to better understand how to implement vis-à-vis, DoDAF, is this the other direction, or is it a two-way street?

Two-way street

Armstrong: It’s a two-way street. One of the big things that particularly the DoD space has going for it is that there’s quite a bit of maturity in the notion of formally specified models, as DoDAF describes them, and the various views that DoDAF includes.

We’d like to think that, because of that maturity, the general TOGAF community can glean a lot of benefit from the experience they’ve had. What does it take to capture these architecture descriptions, some of the finer points about managing some of those assets. People within the TOGAF general community are always looking for case studies and best practices that demonstrate to them that what other people are doing is something that they can do as well.

We also think that the federal agency community also has a lot to glean from this. Again, we’re trying to get some convergence on standard methods and techniques, so that they can more easily have resources join their teams and immediately be productive and add value to their projects, because they’re all based on a standard EA method and framework.

One of the major changes between DoDAF 1 and DoDAF 2 is the focusing on fitness for purpose. In the past, a lot of organizations felt that it was their obligation to describe all architecture viewpoints that DoDAF suggests without necessarily taking a step back and saying, “Why would I want to do that?”

So it’s trying to make the agencies think more critically about how they can be the most agile, mainly what’s the least amount of architecture description that we can invest and that has the greatest possible value. Organizations now have the discretion to determine what fitness for purpose is.

Then, there’s the whole idea in DoDAF 2, that the architecture is supposed to be capability-driven. That is, you’re not just describing architecture, because you have some tools that happened to be DoDAF conforming, but there is a new business capability that you’re trying to inject into the organization through capability-based transformation, which is going to involve people, process, and tools.

One of the nice things that TOGAF’s architecture development method has to offer is a well-defined set of activities and best practices for deciding how you determine what those capabilities are and how you engage your stakeholders to really help collect the requirements for what fit for purpose means.

Gardner: As with the private sector, it seems that everyone needs to move faster. I see you’ve been working on agile development. With organizations like the OMG and Eclipse is there something that doing this well — bringing the best of TOGAF and DoDAF together — enables a greater agility and speed when it comes to completing a project?

Different perspectives

Armstrong: Absolutely. When you talk about what agile means to the general community, you may get a lot of different perspectives and a lot of different answers. Ultimately, we at APG feel that agility is fundamentally about how well your organization responds to change.

If you take a step back, that’s really what we think is the fundamental litmus test of the goodness of an architecture. Whether it’s an EA, a segment architecture, or a system architecture, the architects need to think thoughtfully and considerately about what things are almost certainly going to happen in the near future. I need to anticipate, and be able to work these into my architecture in such a way that when these changes occur, the architecture can respond in a timely, relevant fashion.

We feel that, while a lot of people think that agile is just a pseudonym for not planning, not making commitments, going around in circles forever, we call that chaos, another five letter word. But agile in our experience really demands rigor, and discipline.

Of course, a lot of the culture of the DoD brings that rigor and discipline to it, but also the experience that that community has had, in particular, of formally modeling architecture description. That sets up those government agencies to act agilely much more than others.

Gardner: Do you know of anyone that has done it successfully or is in the process? Even if you can’t name them, perhaps you can describe how something like this works?

Armstrong: First, there has been some great work done by the MITRE organization through their work in collaboration at The Open Group. They’ve written a white paper that talks about which DoDAF deliverables are likely to be useful in specific architecture development method activities. We’re going to be using that as a foundation for the talk we’re going to be giving at the conference in July.

The biggest thing that TOGAF has to offer is that a nascent organization that’s jumping into the DoDAF space may just look at it from an initial compliance perspective, saying, “We have to create an AV-1, and an OV-1, and a SvcV-5,” and so on.

Providing guidance

TOGAF will provide the guidance for what is EA. Why should I care? What kind of people do I need within my organization? What kind of skills do they need? What kind of professional certification might be appropriate to get all of the participants up on the same page, so that when we’re talking about EA, we’re all using the same language?

TOGAF also, of course, has a great emphasis on architecture governance and suggests that immediately, when you’re first propping up your EA capability, you need to put into your plan how you’re going to operate and maintain these architectural assets, once they’ve been produced, so that you can exploit them in some reuse strategy moving forward.

So, the preliminary phase of the TOGAF architecture development method provides those agencies best practices on how to get going with EA, including exactly how an organization is going to exploit what the DoDAF taxonomy framework has to offer.

Then, once an organization or a contractor is charged with doing some DoDAF work, because of a new program or a new capability, they would immediately begin executing Phase A: Architecture Vision, and follow the best practices that TOGAF has to offer.

Just what is that capability that we’re trying to describe? Who are the key stakeholders, and what are their concerns? What are their business objectives and requirements? What constraints are we going to be placed under?

Part of that is to create a high-level description of the current or baseline architecture descriptions, and then the future target state, so that all parties have at least a coarse-grained idea of kind of where we’re at right now, and what our vision is of where we want to be.

Because this is really a high level requirements and scoping set of activities, we expect that that’s going to be somewhat ambiguous. As the project unfolds, they’re going to discover details that may cause some adjustment to that final target.

Internalize best practices

So, we’re seeing defense contractors being able to internalize some of these best practices, and really be prepared for the future so that they can win the greatest amount of business and respond as rapidly and appropriately as possible, as well as how they can exploit these best practices to affect greater business transformation across their enterprises.

Gardner: We mentioned that your discussion on these issues, on July 16 will be Livestreamed for free, but you’re also doing some pre-conference and post-conference activities — webinars, and other things. Tell us how this is all coming together, and for those who are interested, how they could take advantage of all of these.

Armstrong: We’re certainly very privileged that The Open Group has offered this as opportunity to share this content with the community. On Monday, June 25, we’ll be delivering a webinar that focuses on architecture change management in the DoDAF space, particularly how an organization migrates from DoDAF 1 to DoDAF 2.

I’ll be joined by a couple of other people from APG, David Rice, one of our Principal Enterprise Architects who is a member of the DoDAF 2 Working Group, as well as J.D. Baker, who is the Co-chair of the OMG’s Analysis and Design Taskforce, and a member of the Unified Profile for DoDAF and MODAF (UPDM) work group, a specification from the OMG.

We’ll be talking about things that organizations need to think about as they migrate from DoDAF 1 to DoDAF 2. We’ll be focusing on some of the key points of the DoDAF 2 meta-model, namely the rearrangement of the architecture viewpoints and the architecture partitions and how that maps from the classical DoDAF 1.5 viewpoint, as well as focusing on this notion of capability-driven architectures and fitness for purpose.

We also have the great privilege after the conference to be delivering a follow-up webinar on implementation methods and techniques around advanced DoDAF architectures. Particularly, we’re going to take a closer look at something that some people may be interested in, namely tool interoperability and how the DoDAF meta-model offers that through what’s called the Physical Exchange Specification (PES).

We’ll be taking a look a little bit more closely at this UPDM thing I just mentioned, focusing on how we can use formal modeling languages based on OMG standards, such as UML, SysML, BPMN, and SoaML, to do very formal architectural modeling.

One of the big challenges with EA is, at the end of the day, EA comes up with a set of policies, principles, assets, and best practices that talk about how the organization needs to operate and realize new solutions within that new framework. If EA doesn’t have a hand-off to the delivery method, namely systems engineering and solution delivery, then none of this architecture stuff makes a bit of a difference.

Driving the realization

We’re going to be talking a little bit about how DoDAF-based architecture description and TOGAF would drive the realization of those capabilities through traditional systems, engineering, and software development method.

************

For more information on The Open Group’s upcoming conference in Washington, D.C., please visit: http://www.opengroup.org/dc2012

Dana Gardner is president and principal analyst at Interarbor Solutions, an enterprise IT analysis, market research, and consulting firm. Gardner, a leading identifier of software and Cloud productivity trends and new IT business growth opportunities, honed his skills and refined his insights as an industry analyst, pundit, and news editor covering the emerging software development and enterprise infrastructure arenas for the last 18 years.

Comments Off

Filed under Conference, Enterprise Architecture, Enterprise Transformation, TOGAF®

Cybersecurity Threats Key Theme at Washington, D.C. Conference – July 16-20, 2012

By The Open Group Conference Team

Identify risks and eliminating vulnerabilities that could undermine integrity and supply chain security is a significant global challenge and a top priority for governments, vendors, component suppliers, integrators and commercial enterprises around the world.

The Open Group Conference in Washington, D.C. will bring together leading minds in technology and government policy to discuss issues around cybersecurity and how enterprises can establish and maintain the necessary levels of integrity in a global supply chain. In addition to tutorial sessions on TOGAF and ArchiMate, the conference offers approximately 60 sessions on a varied of topics, including:

  • Cybersecurity threats and key approaches to defending critical assets and securing the global supply chain
  • Information security and Cloud security for global, open network environments within and across enterprises
  • Enterprise transformation, including Enterprise Architecture, TOGAF and SOA
  • Cloud Computing for business, collaborative Cloud frameworks and Cloud architectures
  • Transforming DoD avionics software through the use of open standards

Keynote sessions and speakers include:

  • America the Vulnerable: Inside the New Threat Matrix of Digital Espionage, Crime and Warfare - Keynote Speaker: Joel Brenner, author and attorney at Cooley LLP
  • Meeting the Challenge of Cybersecurity Threats through Industry-Government Partnerships - Keynote Speaker: Kristin Baldwin, principal deputy, deputy assistant secretary of defense for Systems Engineering
  • Implementation of the Federal Information Security Management Act (FISMA) - Keynote Speaker: Dr. Ron Ross, project leader at NIST (TBC)
  • Supply Chain: Mitigating Tainted and Counterfeit Products - Keynote Panel: Andras Szakal, VP and CTO at IBM Federal; Daniel Reddy, consulting product manager in the Product Security Office at EMC Corporation; John Boyens, senior advisor in the Computer Security Division at NIST; Edna Conway, chief security strategist of supply chain at Cisco; and Hart Rossman, VP and CTO of Cyber Security Services at SAIC
  • The New Role of Open Standards – Keynote Speaker: Allen Brown, CEO of The Open Group
  • Case Study: Ontario Healthcare - Keynote Speaker: Jason Uppal, chief enterprise architect at QRS
  • Future Airborne Capability Environment (FACE): Transforming the DoD Avionics Software Industry Through the Use of Open Standards - Keynote Speaker: Judy Cerenzia, program director at The Open Group; Kirk Avery of Lockheed Martin; and Robert Sweeney of Naval Air Systems Command (NAVAIR)

The full program can be found here: http://www3.opengroup.org/events/timetable/967

For more information on the conference tracks or to register, please visit our conference registration page. Please stay tuned throughout the next month as we continue to release blog posts and information leading up to The Open Group Conference in Washington, D.C. and be sure to follow the conference hashtag on Twitter – #ogDCA!

1 Comment

Filed under ArchiMate®, Cloud, Cloud/SOA, Conference, Cybersecurity, Enterprise Architecture, Information security, OTTF, Standards, Supply chain risk

RECAP: The Open Group Brazil Conference – May 24, 2012

By Isabela Abreu, The Open Group

Under an autumn Brazilian sky, The Open Group held its first regional event in São Paulo, Brazil, and it turned out to be a great success. More than 150 people attended the conference – including Open Group platinum members (CapGemini, HP, IBM and Oracle), the Brazil chapter of the Association of Enterprise Architecture (AEA), and Brazilian organizations (Daryus, Sensedia) – displaying a robust interest for Enterprise Architecture (EA) within the world’s sixth largest economy. The Open Group also introduced its mission, vision and values to the marketplace – a working model not very familiar to the Brazilian environment.

After the 10 hour, one-day event, I’m pleased to say that The Open Group’s first formal introduction to Brazil was well received, and the organization’s mission was immediately understood!

Introduction to Brazil

The event started with a brief introduction of The Open Group by myself, Isabela Abreu, Open Group country manager of Brazil, and was followed by an impressive presentation by Allen Brown, CEO of The Open Group, on how enterprise architects hold the power to change an organization’s future, and stay ahead of competitors, by using open standards that drive business transformation.

The conference aimed to provide an overview of trending topics, such as business transformation, EA, TOGAF®, Cloud Computing, SOA and Information Security. The presentations focused on case studies, including one by Marcelo Sávio of IBM that showed how the organization has evolved through the use of EA Governance; and one by Roberto Soria of Oracle that provided an introduction to SOA Governance.

Enterprise Architecture

Moving on to architecture, Roberto Severo, president of the AEA in Brazil, pointed out why architects must join the association to transform the Brazil EA community into a strong and ethical tool for transforming EA. He also demonstrated how to align tactical decisions to strategic objectives using Cloud Computing. Then Cecilio Fraguas of CPM Braxis CapGemini provided an introduction to TOGAF®; and Courtnay Guimarães of Instisys comically evinced that although it is sometimes difficult to apply, EA is a competitive tool for investment banks

Security

On the security front, Rodrigo Antão of Apura showed the audience that our enemies know us, but we don’t know them, in a larger discussion about counter-intelligence and cybersecurity; he indicated that architects are wrong when tend to believe EA has nothing to do with Information Security. In his session titled, “OSIMM: How to Measure Success with SOA and Design the Roadmap,” Luís Moraes of Sensedia provided a good overview for architects and explained how to measure success with SOA and design roadmaps with OSIMM - a maturity model of integration services soon to become an ISO standard, based on SOA and developed by The Open Group. Finally, Alberto Favero of Ernst & Young presented the findings of the Ernst & Young 2011 Global Information Security Survey, closing the event.

Aside from the competitive raffle, the real highlight of the event happened at lunch when I noticed the networking between conference attendees. I can testify that the Brazilian EA community actively ideas, in the spirit of The Open Group!

By the end of the day, everybody returned home with new ideas and new friends. I received many inquiries on how to keep the community engaged after the conference, and I promise to keep activities up and running here, in Brazil.

Stay tuned, as we plan sending on a survey to conference attendees, as well the link to all of the presentations. Thanks to everyone who made the conference a great success!

Isabela Abreu is The Open Group country manager for Brazil. She is a member of AEA Brazil and has participated in the translation of the glossary of TOGAF® 9.1, ISO/IEC 20000:1 and ISO/IEC 20000:5 and ITIL V3 to Portuguese. Abreu has worked for itSMF Brazil, EXIN Brazil – Examination Institute for Information Science, and PATH ITTS Consultancy, and is a graduate of São Paulo University.

1 Comment

Filed under Cloud, Conference, Cybersecurity, Enterprise Architecture, TOGAF®

Open CA Candidate Profile: An Interview with Andrey Zaychikov

By Steve Philp, The Open Group

Andrey Zaychikov is CIO and Chief Enterprise Architect Ministry of Sport, Tourism and Youth Policy for the Russian Federation

In February 2012, Andrey Zaychikov became the first Russian to go through the Open CA program via the direct route. He flew to London Heathrow from Moscow to attend the certification board at a local hotel near Heathrow airport and successfully achieved Master Open CA status. We asked him why he wanted to get Open CA certified and how he found the process.

Can you tell us something about yourself in terms of your background and career to date?

I started my career as a software developer with a Master’s degree in computer science and more than five years experience in creating applications using C, C++ and .NET. In those days I was eager to understand how to define the solution requirements and design its implementation, how to deal with the risks, how to organize the communication with customers in a most effective manner. I applied different approaches based on Booch-2 (in early days), then UML etc. They were quite effective (of course, if adopted to the needs of the particular projects and being common-sense) especially talking about small or medium silo applications.

In 2007, I was put in charge of a huge project involving more than 300 organizations within the enterprise and affecting 80 percent of its operational activities. The enormous complexity of this project forced me to look for the other ways to handle it. I found out that enterprise architecture was the only solution to deal with that issue. That was the start of my career as an Enterprise Architect.

Why did you decide to go for Open CA certification?

On the one hand, I had some problems with the quality of assessment of my professional skills and assessment of my approach to defining and governing enterprise architectures, and on the other hand it was a real chance to demonstrate the level of my personal skills and acquirement to the customers, employees, colleagues and competitors.  Besides, it is a good line in a CV to refer to and it will help to boost my career.

Why is Open CA different from other IT certifications that you have previously been involved with?

I chose Open CA Certification Program because it is:

  • Really vendor, country and methods neutral
  • Based on best practices
  • A great challenge to succeed as an Enterprise Architect
  • A unique chance to assess one’s personal skills and acquirement against the world’s best professionals
  • It is linked to a certified professional and not to a company
  • It helps to determine one’s strengths and weaknesses
  • It is instrumental in building one’s personal development and educational plan
  • It is one of the most prestigious enterprise architecture certifications.

In fact, as I thought, it could really help me to define my place in the world of enterprise architecture and to look at myself from another point of view. It helps not only to assess one’s methodological, technical or business skills but also to assess one’s common approach to work in the terms of enterprise architecture.

How did you prepare for Open CA certification?

My preparation was organized in a step-by-step manner.  First of all, I read the Conformance Requirements and a sample package in order to understand what I should do at the first stage of the certification. I used a  self-assessment tool at this stage as well. Then, I completed the experience profiles because it seemed to me to be far easier to write the profiles rather than the questions section first. I wrote the experience profiles in Russian, my native language and then translated them into English. Therefore, it took me approximately twice as much time as estimated by the Certification Board.

Then I answered the questions in the sections. This time I did not translate them – I just wrote the responses straight in English.

After that I did several reviews of my package in order to squeeze it into 50 pages, simplified some responses and diagrams.

While reviewing my package I tried to conform my package with the requirements and made every response clear to the people who are not aware of the current vertical industry and specific project situation. I watched some sitcoms and read a lot of fiction in English for language practice since I did not use English at work.

Having received the review of my package from The Open Group, I made some minor changes in order to clear up some issues.

Then I began preparation for the interview. I read carefully the certification board member handbook to figure out what the Board might be interested in during the interview. I reviewed my package again trying to ask myself as many questions as I could and answered them mentally, in other words, I tried being in interviewers’ shoes.

Then, taking into consideration the time left before the interview, I chose the most important questions and answered only them in English.

Two days before the interview I read thoroughly my package and the questions again. I arrived to London two days before the interview, again in order to practice the language a bit and not to have the linguistic shock.

What benefits do you think having this certification will bring you?

Despite of the fact that the Open CA certification program is not really well known in Russia, it has already brought me some recognition at Russian IT market, especially among vendors as an excellent and unique specialist. Besides, it really helped me to interact with international community. I think it will speed up my career as a CIO and EA in the near future.

What are your plans for future certifications?

I am planning to progress to Open CA Level 3 in a couple of years. I am thinking over PMBOK certification as well, as I often had to fulfill the role of the project manager in some large projects. Plus, I would like to take TOGAF 9 Certification as my TOGAF 8.1.1 has expired and I am going to continue working on my PhD.

Steve Philp is the Marketing Director for the Open CA and Open CITS certification programs at The Open Group. Over the past 20 years, Steve has worked predominantly in sales, marketing and general management roles within the IT training industry. Based in Reading, UK, he joined the Open Group in 2008 to promote and develop the organization’s skills and experience-based IT certifications.

2 Comments

Filed under Certifications, Enterprise Architecture, Professional Development, Uncategorized