Category Archives: TOGAF

The Open Group Certified Architect (Open CA) Program Transformed My Career

By Bala Prasad Peddigari, Tata Consultancy Services Limited

openca

Learning has been a continuous journey for me throughout my career, but certification in TOGAF® truly benchmarked my knowledge and Open CA qualified my capability as a practitioner. Open CA not only tested my skills as a practitioner, but also gave me valuable recognition and respect as an Enterprise Architect within my organization.

When I was nominated to undergo the Open CA Certification in 2010, I didn’t realize that this certification would transform my career, improve my architecture maturity and provide me with the such wide spread peer recognition.

The Open CA certification has enabled me to gain increased recognition at my organization. Furthermore, our internal leadership recognizes my abilities and has helped me to get into elite panels of jury regarding key initiatives at the organization level and at my parent company’s organization level. The Open CA certification has helped me to improve my Architecture Maturity and drive enterprise solutions.

With recognition, comes a greater responsibility – hence my attempt to create a community of architects to within my organization and expand the Enterprise Architecture culture. I started the Architects Cool Community a year ago. Today, this community has grown to roughly 350 associates who continuously share knowledge, come together to solve architecture problems, share best practices and contribute to The Open Group Working Groups to build reference architectures.

I can without a doubt state that TOGAF and Open CA have made a difference in my career transformation: they created organization-wide visibility, helped me to get both internal and external recognition as an Enterprise Architect and helped me to achieve required growth. My Open CA certification has also been well received by customers, particularly when I meet enterprise customers from Australia and the U.S. The Open CA certification exemplifies solid practitioner knowledge and large-scale end-to-end thinking. The certification also provided me with self-confidence in architecture problem solving to drive the right rationale.

I would like to thank my leadership team, who provided the platform and offered lot of support to drive the architecture initiatives. I would like to thank The Open Group’s Open CA team and the board who interviewed me to measure and certify my skills. I strongly believe you earn the certification because you are able to support your claims to satisfy the conformance requirements and achieving it proves that you have the skills and capabilities to carry out architecture work.

You can find out if you can meet the requirements of the program by completing the Open CA Self Assessment Tool.

balaBala Prasad Peddigari (Bala) is an Enterprise Architect and Business Value Consultant with Tata Consultancy Services Limited. Bala specializes in Enterprise Architecture, IT Strategies, Business Value consulting, Cloud based technology solutions and Scalable architectures. Bala has been instrumental in delivering IT Solutions for Finance, Insurance, Telecom and HiTech verticals. Bala currently heads the HiTech Innovative Solutions Technology Excellence Group with a focus on Cloud, Microsoft, Social Computing, Java and Open source technologies. He received accolades in Microsoft Tech Ed for his cloud architectural strengths and Won the Microsoft ALM Challenge. Bala published his papers in IEEE and regular speaker in Open Group conference and Microsoft events. Bala serves on the Open CA Certification Board for The Open Group.

Comments Off on The Open Group Certified Architect (Open CA) Program Transformed My Career

Filed under Certifications, Open CA, Professional Development, TOGAF, TOGAF®

The Open Group Sydney – My Conference Highlights

By Mac Lemon, MD Australia at Enterprise Architects

Sydney

Well the dust has settled now with the conclusion of The Open Group ‘Enterprise Transformation’ Conference held in Sydney, Australia for the first time on April 15-20. Enterprise Architects is proud to have been recognised at the event by The Open Group as being pivotal in the success of this event. A number of our clients including NBN, Australia Post, QGC, RIO and Westpac presented excellent papers on leading edge approaches in strategy and architecture and a number of EA’s own thought leaders in Craig Martin, Christine Stephenson and Ana Kukec also delivered widely acclaimed papers.

Attendance at the conference was impressive and demonstrated that there is substantial appetite for a dedicated event focussed on the challenges of business and technology strategy and architecture. We saw many international visitors both as delegates and presenting papers and there is no question that a 2014 Open Group Forum will be the stand out event in the calendar for business and technology strategy and architecture professionals.

My top 10 take-outs from the conference include the following:

  1. The universal maturing in understanding the criticality of Business Architecture and the total convergence upon Business Capability Modelling as a cornerstone of business architecture;
  2. The improving appreciation of techniques for understanding and expressing business strategy and motivation, such as strategy maps, business model canvass and business motivation modelling;
  3. That customer experience is emerging as a common driver for many transformation initiatives;
  4. While the process for establishing the case and roadmap for transformation appears well enough understood, the process for management of the blueprint through transformation is not and generally remains a major program risk;
  5. Then next version of TOGAF® should offer material uplift in support for security architecture which otherwise remains at low levels of maturity from a framework standardisation perspective;
  6. ArchiMate® is generating real interest as a preferred enterprise architecture modelling notation – and that stronger alignment of ArchiMate® and TOGAF® meta models in then next version of TOGAF® is highly anticipated;
  7. There is industry demand for recognised certification of architects to demonstrate learning alongside experience as the mark of a good architect. There remains an unsatisfied requirement for certification that falls in the gap between TOGAF® and the Open CA certification;
  8. Australia can be proud of its position in having the second highest per capita TOGAF® certification globally behind the Netherlands;
  9. While the topic of interoperability in government revealed many battle scarred veterans convinced of the hopelessness of the cause – there remain an equal number of campaigners willing to tackle the challenge and their free and frank exchange of views was entertaining enough to justify worth the price of a conference ticket;
  10. Unashamedly – Enterprise Architects remains in a league of its own in the concentration of strategy and architecture thought leadership in Australia – if not globally.

Mac LemonMac Lemon is the Managing Director of Enterprise Architects Pty Ltd and is based in Melbourne, Australia.

This is an extract from Mac’s recent blog post on the Enterprise Architects web site which you can view here.

Comments Off on The Open Group Sydney – My Conference Highlights

Filed under ArchiMate®, Business Architecture, Certifications, Conference, Enterprise Architecture, Enterprise Transformation, Professional Development, Security Architecture, TOGAF, TOGAF®

What is Business Architecture?

By Allen Brown, President and CEO, The Open Group

I have heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in their job title.  So I wrote to 183 people in Australia and New Zealand and asked them.

I chose Australia and New Zealand because of our conference in Sydney that was coming up at the time.  It is also worth mentioning that when counting the number of individuals in each country who have achieved TOGAF®9 certification, Australia is ranked 4th in the world and New Zealand is 20th.

I explained that I had thought of constructing a survey instrument but I always think that such an approach is only really suitable when you want to measure opinion on things that you know.  Since I really wanted to have an open mind, I asked everyone for their thoughts and provided a small number of open questions that showed the sort of thing I was interested in learning.

These were:

  • What is Business Architecture in the context of your organization?
  • Do you have Enterprise Architects in your organization? If so, what is it that you do that they do not? If not, how do you see Business Architecture differently from Enterprise Architecture?
  • Who do you report to? Is your line of reporting up to the CIO, the COO if you have one, or other senior level person?
  • How is Business Architecture perceived in your organization?

 It would also help me if I knew something about your organization.
  • Which industry are you in? e.g. IT, Oil, Finance, Healthcare, National or Local Government, etc.?
  • Is your organization primarily a consumer of Business Architecture or a supplier? e.g. consultant, trainer, vendor etc.
  • What type of organization do you work in? e.g. a for-profit entity, a government department, a charity, etc.
  • How big is the organization? Some idea of revenue or budget, number of employees – doesn’t have to be precise. You could just say small, medium or large.
  • How many Business Architects, Enterprise Architects or other architects are there in your organization?

And perhaps a little about yourself.
  • Your background e.g. Operations, Business Analysis, Project Management, IT, Finance etc.
  • Were you recruited for the role or did you develop into it?
  • I don’t wish to take up too much of your time but anything you can share would be very helpful. And please feel free to add anything else that you feel is relevant.

I have so far received 24 responses which is what I was hoping for but I am open to any other views people who are performing this role might have.  16 of the responses came from people employed by organizations that I think of as consumers of IT products and services (government departments, telcos, banks, accountants, energy companies, and mutuals) and 8 came from suppliers.

The responses were amazing and thank you to everyone who took the time to do so.  They included some wonderful insights into their role and into their organization, without of course divulging anything that they should not have.  But of course because I asked open questions, the responses are, at the same time both more complex and more interesting.  It’s a case of be careful of what you wish for – but I am really glad that I did.

So far I have been able to summarize the views of the consumers.  I will turn to the suppliers next.  It will be really interesting to see where the similarities and variations lay.

It is important to note that I am still in the process of seeking to understand, so I would be really pleased to hear from anyone who has such a role, to correct any misunderstandings I might have or erroneous conclusions I may have drawn.

A number of comments jumped out at me.  One example came from a Business Architect in a government department.  The reason it stood out was very simple.  Many times I am told that Business Architecture only applies to commercial business and cannot apply to governments or non-profits.  Which is strange to me, since I lead a non-profit and when I was at business school, part-time of course, a good proportion of my classmates were from the public sector.  The comment was in response to the question: who do you report to?  The answer was, “we report to the Secretary but all reporting lines are business focused”.

The first level of analysis, which should come as no surprise is that Business Architecture is a relatively new discipline for most organizations: in most cases it has been around for between 1 and 5 years.  Described by some as a growing capability, or as immature, or even as “largely missing”.  One respondent describes herself quite rightly as a pioneer.

A recurring theme was that the ability to have a company-wide or industry-wide model was critical as it provides a common terminology across the board to what the organization actually does and enables understanding of the implications of any changes.  Another was that the success or lack of it in Business Architecture really came down to the expertise of the people in the team; and another was that Business Architects acted very much, like internal consultants and often had a consulting background.

What Business Architects do is exactly that – their focus is on the “What”.  Some of the comments included:

  • Understanding strategic themes and drivers
  • Modeling value chains, value streams, configurations
  • Context modeling e.g. external interactions
  • Capabilities, including business capability, service capability (including both business and IT capabilities), capability maturity, targets and gaps
  • Calling out the interdependencies of all the business and architecture domains: strategy, governance, market, distribution, product, capability
  • Design – entities, people (organization structure, incentives), process, systems, functions, roles
  • Linking with and supporting the strategy and injecting into the investment planning cycle
  • The Business Architect provides processes, part of the input and information for the business to determine whether or not any investment will be made within their organisation

The “How” is in the domain of the Solution Architects, Application, Data and Technology Architects and the Business Analysts: business, process and data.

The crucial element is how well the Business Architects are integrated with the other architects and with the analysts.  In many cases Business Architecture was within the Enterprise Architecture function – as an aside it was pointed out by one or two respondents that they considered Enterprise Architecture as a function rather than a person – in other cases it was not.

The reporting lines for Business Architects varies from organization to organization.  Some reporting lines ultimately end up with the CIO or CTO, others to the COO and others did not.  In many cases they reported directly to a GM or Head of change management, transformation or business strategy or improvement.

In those cases where Business Architecture was not embedded within the Enterprise Architecture function the relationship was enabled via a forum or committee that brought the Business Architects together with those working on the other disciplines.   Gaining agreement on a common content framework, on business modeling standards and on governance procedures were cited as approaches that supported the collaboration.

Although in one case, Business Architecture was relegated to a sub-discipline of IT architecture to focus on the “business stuff”.  In most cases the Business Architects described a differentiated focus or role.

  • A focus on business performance, process design, organization design, strategy and planning
  • The documentation and governance of business processes, organizational elements, business requirements, regulatory requirements, business rules and risks
  • The description of what we are trying to do, what value it adds and how it can be done

The difference from the other architecture domains was often described under the general heading of technology.

  • Technical architecture and governance
  • Strategic solutioning
  • Information, application, data architecture
  • Portfolio management
  • The enterprise stack of tools
  • Innovation through new technology

Business Architecture often demands a certain amount of analysis work and in one case it was seen as glorified business analysis. I have also heard “industry experts” say that they do not understand the difference between Business Architects and Business Analysts.  But that is unfair both to the Business Architects and to the Business Analysts.  They are both important functions in their own right.  In fact it has been emphasized that you need all three disciplines: Business Analyst, Business Architect and the Solution, Information, Technology Architect.

Perhaps in smaller organizations you might get by with a Jack of all trades but the size of the organization represented by these respondents ranged from 1,500 employees to 50,000 employees and they need the benefit of the three different specializations.

While the Business Analysts are the source of the very detailed information needed, the Business Architect brings the skills needed to distil that information and discuss it with the business leaders.  The people they are talking with are the senior leaders, the strategic solutioning teams, the program directors of large change programs and others who need pragmatic, easily digestible information.  They need to understand the implications and gaps, the dependencies, the opportunities and the limitations.

As one person said, “the success gauge for Business Architecture is an organization that starts solving business problems by defining them within the organization’s context across the spectrum of change areas, minus the technology change area, and then works toward the technology, rather than starting at a technology solution that might solve the problem and playing catch-up from there.  I continue to hold to the view that investing in the Business Architecture up front saves on people, process and technology cost at the end.”

Again, I would like to thank everyone for taking the time to respond.  Everyone has a valuable story to tell and everyone is fully committed to the role and function of the Business Architect.  If I have misunderstood anything, please do not hesitate to correct me. I look forward to hearing your comments.

Allen Brown

Allen Brown is President and CEO, The Open Group – a global consortium that enables the achievement of business objectives through IT standards.  For over 14 years Allen has been responsible for driving The Open Group’s strategic plan and day-to-day operations, including extending its reach into new global markets, such as China, the Middle East, South Africa and India. In addition, he was instrumental in the creation of the AEA, which was formed to increase job opportunities for all of its members and elevate their market value by advancing professional excellence.

2 Comments

Filed under Business Architecture, Certifications, Enterprise Architecture, Enterprise Transformation, Professional Development, TOGAF

The Center of Excellence: Relating Everything Back to Business Objectives

By Serge Thorn, Architecting the Enterprise

This is the third and final installment of a 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, my second blog post suggested how the Center of Excellence would define a Reference Architecture for the organization.

 SOA principles should clearly relate back to the business objectives and key architecture drivers. They will be constructed on the same mode as TOGAF 9.1 principles with the use of statement, rationale and implications. Below examples of the types of services which may be created:

  • Put the computing near the data
  • Services are technology neutral
  • Services are consumable
  • Services are autonomous
  • Services share a formal contract
  • Services are loosely coupled
  • Services abstract underlying logic
  • Services are reusable
  • Services are composable
  • Services are stateless
  • Services are discoverable
  • Location Transparency

Here is a detailed principle example:

  • Service invocation
    • All service invocations between application silos will be exposed through the Enterprise Service Bus (ESB)
    • The only exception to this principle will be when the service meets all the following criteria:
      • It will be used only within the same application silo
      • There is no potential right now or in the near future for re-use of this service
      • The service has already been right-sized
      • The  Review Team has approved the exception

As previously indicated, the SOA Center of Excellence (CoE) would also have to provide guidelines on SOA processes and related technologies. This may include:

  • Service analysis (Enterprise Architecture, BPM, OO, requirements and models, UDDI Model)
  • Service design (SOAD, specification, Discovery Process, Taxonomy)
  • Service provisioning (SPML, contracts, SLA)
  • Service implementation development (BPEL, SOAIF)
  • Service assembly and integration (JBI, ESB)
  • Service testing
  • Service deployment (the software on the network)
  • Service discovery (UDDI, WSIL, registry)
  • Service publishing (SLA, security, certificates, classification, location, UDDI, etc.)
  • Service consumption (WSDL, BPEL)
  • Service execution  (WSDM)
  • Service versioning (UDDI, WSDL)
  • Service Management and monitoring
  • Service operation
  • Programming, granularity and abstraction

Other activities may be considered by the SOA CoE such as providing a collaboration platform, asset management (service are just another type of assets), compliance with standards and best practices, use of guidelines, etc. These activities could also be supported by an Enterprise Architecture team.

As described in the TOGAF® 9.1 Framework, the SOA CoE can act as the governance body for SOA implementation, work with the Enterprise Architecture team, overseeing what goes into a new architecture that the organization is creating and ensuring that the architecture will meet the current and future needs of the organization.

The Center of Excellence provides expanded opportunities for organizations to leverage and reuse service-oriented infrastructure and knowledgebase to facilitate the implementation of cost-effective and timely SOA based solutions.

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 on The Center of Excellence: Relating Everything Back to Business Objectives

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

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 on Creating Reference Architecture: The Center of Excellence

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 on Implementing SOA through TOGAF 9.1: The Center Of Excellence

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

What’s New in ArchiMate 2.0?

By Andrew Josey, The Open Group, Henry Franken, BiZZdesign

ArchiMate® 2.0, an Open Group Standard, is an upwards-compatible evolution from ArchiMate 1.0 adding new features, as well as addressing usage feedback and comments raised.

ArchiMate 2.0 standard supports modeling throughout the TOGAF Architecture Development Method (ADM).

Figure 1: Correspondence between ArchiMate and the TOGAF ADM

ArchiMate 2.0 consists of:

  • The ArchiMate Core, which contains several minor improvements on the 1.0 version.
  • The Motivation extension, to model stakeholders, drivers for change, business goals, principles, and requirements. This extension mainly addresses the needs in the early TOGAF phases and the requirements management process.
  • The Implementation and Migration extension, to support project portfolio management, gap analysis, and transition and migration planning. This extension mainly addresses the needs in the later phases of the TOGAF ADM cycle.

ArchiMate 2.0 offers a modeling language to create fully integrated models of the organization’s enterprise architecture, the motivation for the enterprise architecture, and the programs, projects and migration paths to implement this enterprise architecture. In this way, full (forward and backward) traceability between the elements in the enterprise architecture, their motivations and their implementation can be obtained.

In the ArchiMate Core, a large number of minor improvements have been made compared to ArchiMate 1.0: inconsistencies have been removed, examples have been improved and additional text has been inserted to clarify certain aspects. Two new concepts have been added based on needs experienced by practitioners:

  • Location: To model a conceptual point or extent in space that can be assigned to structural elements and, indirectly, of behavior elements.
  • Infrastructure Function: To model the internal behavior of a node in the technology layer. This makes the technology layer more consistent with the other two layers.

The Motivation extension defines the following concepts:

  • Stakeholder: The role of an individual, team, or organization (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture.
  • Driver: Something that creates, motivates, and fuels the change in an organization.
  • Assessment: The outcome of some analysis of some driver.
  • Goal: An end state that a stakeholder intends to achieve.
  • Requirement: A statement of need that must be realized by a system.
  • Constraint: A restriction on the way in which a system is realized.
  • Principle: A normative property of all systems in a given context or the way in which they are realized.

For motivation elements, a limited set of relationships has been defined, partly re-used from the ArchiMate Core: aggregation (decomposition), realization, and (positive or negative) influence.

The Implementation and Migration extension defines the following concepts (and re-uses the relationships of the Core):

  • Work Package: A series of actions designed to accomplish a unique goal within a specified time.
  • Deliverable: A precisely defined outcome of a work package.
  • Plateau: A relatively stable state of the architecture that exists during a limited period of time.
  • Gap: An outcome of a gap analysis between two plateaus.

ArchiMate 2 Certification

New with ArchiMate 2.0 is the introduction of a certification program. This includes certification for people and accreditation for training courses. It also includes certification for tools supporting the ArchiMate standard.

The ArchiMate 2 Certification for People program enables professionals around the globe to demonstrate their knowledge of the ArchiMate standard. ArchiMate 2 Certification for People is achieved through an examination and practical exercises as part of an Accredited ArchiMate 2 Training Course.

The Open Group Accreditation for ArchiMate training courses provides an authoritative and independent assurance of the quality and relevance of the training courses.

The Open Group ArchiMate Tool Certification Program makes certification available to tools supporting ArchiMate. The goal of the program is to ensure that architecture artifacts created with a certified tool are conformant to the language.

Further Reading

ArchiMate 2.0 is available for online reading and download from The Open Group Bookstore at www.opengroup.org/bookstore/catalog/c118.htm.

A white paper with further details on ArchiMate 2.0 is available to download from The Open Group Bookstore at www.opengroup.org/bookstore/catalog/w121.htm .

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.

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.

Comments Off on What’s New in ArchiMate 2.0?

Filed under ArchiMate®, Business Architecture, Enterprise Architecture, Standards, TOGAF, TOGAF®