Tag Archives: TOGAF

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

By Serge Thorn, Architecting the Enterprise

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

Let’s start with a definition of traceability. Traceable is an adjective; capable of being traced. Trying to find a definition even from a dictionary is a challenge and the most relevant one I found on Wikipedia which may be used as a reference could be “The formal definition of traceability is the ability to chronologically interrelate uniquely identifiable entities in a way that is verifiable.”

In Enterprise Architecture, traceability may mean different things to different people.

Some people refer to

  • Enterprise traceability which proves alignment to business goals
  • End-to-end traceability to business requirements and processes
  • A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities
  • Requirements traceability which  assists  in quality  solutions that meets the business needs
  • Traceability between requirements and TOGAF artifacts
  • Traceability across artifacts
  • Traceability of services to business processes and architecture
  • Traceability from application to business function to data entity
  • Traceability between a technical component and a business goal
  • Traceability of security-related architecture decisions
  • Traceability of IT costs
  • Traceability to tests scripts
  • Traceability between  artifacts from business and IT strategy to solution development and delivery
  • Traceability from the initial design phase through to deployment
  • And probably more

The TOGAF 9.1 specification rarely refers to traceability and the only sections where the concept is used are in the various architecture domains where we should document a requirements traceability report or traceability from application to business function to data entity.

The most relevant section is probably where in the classes of architecture engagement it says:

“Using the traceability between IT and business inherent in enterprise architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.”

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

serge1In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

serge2Using the TOGAF 9.1 framework, we would use concepts of the Metamodel. The core metamodel entities show the purpose of each entity and the key relationships that support architectural traceability as stipulated in the section 34.2.1 Core Content Metamodel Concepts.

So now, how do we build that traceability? This is going to happen along the various ADM cycles that an enterprise will support. It is going to be quite a long process depending on the complexity, the size and the various locations where the business operates.

There may be five different ways to build that traceability:

  • Manually using an office product
  • With an enterprise architecture tool not linked to the TOGAF 9.1 framework
  • With an enterprise architecture tool using the TOGAF 9.1 artifacts
  • With an enterprise architecture tool using ArchiMate 2.0
  • Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

1. Manually using an office product

You will probably document your architecture with the use of word processing, spread sheets and diagramming tools and store these documents in a file structure on a file server, ideally using some form of content management system.

Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system or an enterprise. The links between these deliverables soon becomes non manageable and in the long term impact analysis of any change will become quite impossible. Information will be hard to find and to trace from requirements all the way back to the business goal that drives it. This is particularly difficult to achieve when requirements are stored in spread sheets and use cases and business goals are contained in separate documents. Other issues such as maintenance and consistency would have to be considered.

serge3

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Many enterprise architecture tools or suites provide different techniques to support traceability but do not really describe how things work and focus mainly on describing requirements traceability.  In the following example, we use a traceability matrix between user requirements and functional specifications, use cases, components, software artifacts, test cases, business processes, design specifications and more.

Mapping the requirements to use cases and other information can be very labor-intensive.

serge4

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

Below is an example of what traceability would look like in an enterprise architecture tool after some time.  That enterprise architecture ensures appropriate traceability from business architecture to the other allied architectures.

serge5

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

The TOGAF 9.1 core metamodel provides a minimum set of architectural content to support traceability across artifacts. Usually we use catalogs, matrices and diagrams to build traceability independently of dragging lines between elements (except possibly for the diagrams). Using catalogs and matrices are activities which may be assigned to various stakeholders in the organisation and theoretically can sometimes hide the complexity associated with an enterprise architecture tool.

serge6Using artifacts creates traceability. As an example coming from the specification; “A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified”. There are other artifacts which also describe other traceability: Data Migration Diagram and Networked Computing/Hardware Diagram.

4. With an enterprise architecture tool using ArchiMate 2.0

Another possibility could be the use of the ArchiMate standard from The Open Group. Some of the that traceability could  also be achievable in some way using BPMN and UML for specific domains such as process details in Business Architecture or building the bridge between Enterprise Architecture and Software architecture.

With ArchiMate 2.0 we can define the end to end traceability and produce several viewpoints such as the Layered Viewpoint which shows several layers and aspects of an enterprise architecture in a single diagram. Elements are modelled in five different layers when displaying the enterprise architecture; these are then linked with each other using relationships. We differentiate between the following layers and extensions:

  • Business layer
  • Application layer
  • Technology layer
  • Motivation extension
  • Implementation and migration extension

The example from the specification below documents the various architecture layers.

serge7
As you will notice, this ArchiMate 2.0 viewpoint looks quite similar to the TOGAF 9.1 Business Footprint Diagram which provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.

Another example could be the description of the traceability among business goals, technical capabilities, business benefits and metrics.  The key point about the motivation extension is to work with the requirement object.

Using the motivation viewpoint from the specification as a reference (motivation extension), you could define business benefits / expectations within the business goal object, and then define sub-goals as KPIs to measure the benefits of the plan and list all of the identified requirements of the project / program.  Finally, you could link these requirements with either application or infrastructure service object representing software or technical capabilities. (Partial example below).

serge8
One of the common questions I have recently received from various enterprise architects is “Now that I know TOGAF and ArchiMate… how should I model my enterprise? Should I use the TOGAF 9.1 artifacts to create that traceability? Should I use ArchiMate 2.0? Should I use both? Should I forget the artifacts…”. These are good questions and I’m afraid that there is not a single answer.

What I know is that if I select an enterprise architecture tool supporting both TOGAF 9.1 and ArchiMate 2.0, I would like to be able to be able to have a full synchronization. If I model a few ArchiMate models I would like my TOGAF 9.1 artifacts to be created at the same time (catalogs and matrices) and if I create artifacts from the taxonomy, I would like my ArchiMate models also to be created.

Unfortunately I do not know the current level of tools maturity and whether tools vendors provide that synchronization. This would obviously require some investigation and should be one of the key criteria if you were currently looking for a product supporting both standards.

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

This other possibility requires that you have an up to date Configuration Management Database and that you developed an interface with your Architecture Repository, your enterprise architecture tool. If you are able to replicate the relationships between the infrastructure components and applications (CIs) into your enterprise architecture tool that would partially create your traceability.

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

serge9
Achieving traceability within an Enterprise Architecture is key because the architecture needs to be understood by all participants and not just by technical people.  It helps to incorporate the enterprise architecture efforts into the rest of the organization and it takes it to the board room (or at least the CIO’s office) where it belongs.

  • Describe your traceability from your Enterprise Architecture to the system development and project documentation.
  • Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

If a development team is looking for a tool that can help them document, and provide end to end traceability throughout the life cycle EA is the way to go, make sure you use the right standard and platform. Finally, communicate and present to your stakeholders the results of your effort.

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.

2 Comments

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

TOGAF® 9 Certification Reaches 25,000 Milestone

By Andrew Josey, The Open Group

Last Wednesday represented a significant milestone for The Open Group’s TOGAF® 9 certification program. In case you hadn’t already seen it on our homepage, Twitter, or LinkedIn,  the number of TOGAF® 9 certified individuals has now surpassed the 25,000 mark, an increase of nearly 8,500 new certifications in the equivalent twelve month period!

For those of you who might be unfamiliar with the name, TOGAF®, an Open Group Standard, is a proven enterprise architecture methodology and framework used by the world’s leading organizations to improve business efficiency.

Certification is available to individuals who wish to demonstrate they have attained the required knowledge and understanding of the current standard, and reaching the 25,000 mark is of course an incredible milestone for TOGAF®.

However, Wednesday’s milestone isn’t the only positive reflection of TOGAF adoption in recent times. Just weeks ago, the latest Foote report placed TOGAF® skills and Open CA certification (an Open Group Certification) top of the 340 highest paying non-certified and 289 highest paying certified IT skills, respectively.

The report, based on US and Canadian data, stated that: “vendor independent organizations such as The Open Group have far fewer resources for promoting their programs but what they do have are superb architecture certifications that employers need and highly value and we see their certifications holding their value if not gaining ground.”

There is no doubt that the success of both can be partially attributed to a huge surge in the popularity of open standards over the last few years – including TOGAF® and Open CA.

The economic downturn has its role to play here of course. Since the financial crisis began, open standards have helped by providing a framework that allows Enterprise Architects to save their companies money, maintain and increase profitability and drive business efficiencies. And, on a professional level, certification has helped Enterprise Architects to differentiate themselves, delivering better job security and employment prospects through testing times.

However, with the worst of the financial crisis hopefully behind us, the rate of certifications shows little signs of slowing. The below graph outlines the rise in the number of TOGAF® 9 certifications since March 2009:

TOGAF certs v2
As you can see from the graph, there are two levels defined for TOGAF 9 “people certification”, and these are known as TOGAF 9 Foundation and TOGAF 9 Certified, respectively.

To provide you with a brief background on these, certification to TOGAF 9 Foundation demonstrates that the candidate has gained knowledge of the terminology, structure, and basic concepts of TOGAF 9, and also understands the core principles of enterprise architecture and the TOGAF standard. Certification to TOGAF 9 Certified provides validation that in addition to the knowledge and comprehension of TOGAF 9 Foundation, the candidate is able to analyze and apply this knowledge.

However, while there are now fifty TOGAF 9 training partners across the globe and fifty-eight accredited TOGAF 9 courses to choose from, more and more of these certifications are self taught. At the last count we had sold over 7700 electronic self study packs for TOGAF 9 certification, making it the number one best-seller in our electronic commerce store. These have proved particularly popular in smaller global markets where face-to-face training courses may be less accessible or costly.

Of course, as we celebrate a great milestone in its evolution, credit must go out to the many people who have helped develop and continue to help develop the TOGAF® standard, in particular the members of The Open Group Architecture Forum. Today’s milestone is not only a testament to the value placed in trusted, globally accepted standards supported through certification, but to their endeavours.

It was not so long ago we announced on this very blog that TOGAF® had become a globally recognized, registered brand trademark. Now, just a few months later, we celebrate another significant milestone in the evolution of TOGAF®. Long may this evolution (and the milestones) continue!

More information on TOGAF 9 Certification, including the directory of Certified professionals and the official accredited training course calendar, can be obtained from The Open Group website here: http://www.opengroup.org/togaf9/cert/

See our TOGAF 9 infographic for the latest statistics:

TOGAFInfograph-full-450

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, Enterprise Architecture, TOGAF, TOGAF®

Gaining Dependability Across All Business Activities Requires Standard of Standards to Tame Dynamic Complexity, Says The Open Group CEO

By Dana Gardner, Interarbor Solutions

Listen to the recorded podcast here

Hello, and welcome to a special BriefingsDirect Thought Leadership

Interview series, coming to you in conjunction with The Open Group Conference on July 15, in Philadelphia.

88104-aaadanaI’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator throughout these discussions on enterprise transformation in the finance, government, and healthcare sector.

We’re here now with the President and CEO of The Open Group, Allen Brown, to explore the increasingly essential role of standards, in an undependable, unpredictable world. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

Welcome back, Allen.

Allen Brown: It’s good to be here, Dana. abrown

Gardner: What are the environmental variables that many companies are facing now as they try to improve their businesses and assess the level of risk and difficulty? It seems like so many moving targets.

 Brown: Absolutely. There are a lot of moving targets. We’re looking at a situation where organizations are having to put in increasingly complex systems. They’re expected to make them highly available, highly safe, highly secure, and to do so faster and cheaper. That’s kind of tough.

Gardner: One of the ways that organizations have been working towards a solution is to have a standardized approach, perhaps some methodologies, because if all the different elements of their business approach this in a different way, we don’t get too far too quickly, and it can actually be more expensive.

Perhaps you could paint for us the vision of an organization like The Open Group in terms of helping organizations standardize and be a little bit more thoughtful and proactive towards these changed elements?

Brown: With the vision of The Open Group, the headline is “Boundaryless Information Flow.” That was established back in 2002, at a time when organizations were breakingdown the stovepipes or the silos within and between organizations and getting people to work together across functioning. They found, having done that, or having made some progress towards that, that the applications and systems were built for those silos. So how can we provide integrated information for all those people?

As we have moved forward, those boundaryless systems have become bigger

and much more complex. Now, boundarylessness and complexity are giving everyone different types of challenges. Many of the forums or consortia that make up The Open Group are all tackling it from their own perspective, and it’s all coming together very well.

We have got something like the Future Airborne Capability Environment (FACE) Consortium, which is a managed consortium of The Open Group focused on federal aviation. In the federal aviation world they’re dealing with issues like weapons systems.

New weapons

Over time, building similar weapons is going to be more expensive, inflation happens. But the changing nature of warfare is such that you’ve then got a situation where you’ve got to produce new weapons. You have to produce them quickly and you have to produce them inexpensively.

So how can we have standards that make for more plug and play? How can the avionics within a cockpit of whatever airborne vehicle be more interchangeable, so that they can be adapted more quickly and do things faster and at lower cost.

After all, cost is a major pressure on government departments right now.

We’ve also got the challenges of the supply chain. Because of the pressure on costs, it’s critical that large, complex systems are developed using a global supply chain. It’s impossible to do it all domestically at a cost. Given that, countries around the world, including the US and China, are all concerned about what they’re putting into their complex systems that may have tainted or malicious code or counterfeit products.

The Open Group Trusted Technology Forum (OTTF) provides a standard that ensures that, at each stage along the supply chain, we know that what’s going into the products is clean, the process is clean, and what goes to the next link in the chain is clean. And we’re working on an accreditation program all along the way.

We’re also in a world, which when we mention security, everyone is concerned about being attacked, whether it’s cybersecurity or other areas of security, and we’ve got to concern ourselves with all of those as we go along the way.

Our Security Forum is looking at how we build those things out. The big thing about large, complex systems is that they’re large and complex. If something goes wrong, how can you fix it in a prescribed time scale? How can you establish what went wrong quickly and how can you address it quickly?

If you’ve got large, complex systems that fail, it can mean human life, as it did with the BP oil disaster at Deepwater Horizon or with Space Shuttle Challenger. Or it could be financial. In many organizations, when something goes wrong, you end up giving away service.

An example that we might use is at a railway station where, if the barriers don’t work, the only solution may be to open them up and give free access. That could be expensive. And you can use that analogy for many other industries, but how can we avoid that human or financial cost in any of those things?

A couple of years after the Space Shuttle Challenger disaster, a number of criteria were laid down for making sure you had dependable systems, you could assess risk, and you could know that you would mitigate against it.

What The Open Group members are doing is looking at how you can get dependability and assuredness through different systems. Our Security Forum has done a couple of standards that have got a real bearing on this. One is called Dependency Modeling, and you can model out all of the dependencies that you have in any system.

Simple analogy

A very simple analogy is that if you are going on a road trip in a car, you’ve got to have a competent driver, have enough gas in the tank, know where you’re going, have a map, all of those things.

What can go wrong? You can assess the risks. You may run out of gas or you may not know where you’re going, but you can mitigate those risks, and you can also assign accountability. If the gas gauge is going down, it’s the driver’s accountability to check the gauge and make sure that more gas is put in.

We’re trying to get that same sort of thinking through to these large complex systems. What you’re looking at doing, as you develop or evolve large, complex systems, is to build in this accountability and build in understanding of the dependencies, understanding of the assurance cases that you need, and having these ways of identifying anomalies early, preventing anything from failing. If it does fail, you want to minimize the stoppage and, at the same time, minimize the cost and the impact, and more importantly, making sure that that failure never happens again in that system.

The Security Forum has done the Dependency Modeling standard. They have also provided us with the Risk Taxonomy. That’s a separate standard that helps us analyze risk and go through all of the different areas of risk.

Now, the Real-time & Embedded Systems Forum has produced the Dependability through Assuredness, a standard of The Open Group, that brings all of these things together. We’ve had a wonderful international endeavor on this, bringing a lot of work from Japan, working with the folks in the US and other parts of the world. It’s been a unique activity.

Dependability through Assuredness depends upon having two interlocked cycles. The first is a Change Management Cycle that says that, as you look at requirements, you build out the dependencies, you build out the assurance cases for those dependencies, and you update the architecture. Everything has to start with architecture now.

You build in accountability, and accountability, importantly, has to be accepted. You can’t just dictate that someone is accountable. You have to have a negotiation. Then, through ordinary operation, you assess whether there are anomalies that can be detected and fix those anomalies by new requirements that lead to new dependabilities, new assurance cases, new architecture and so on.

The other cycle that’s critical in this, though, is the Failure Response Cycle. If there is a perceived failure or an actual failure, there is understanding of the cause, prevention of it ever happening again, and repair. That goes through the Change Accommodation Cycle as well, to make sure that we update the requirements, the assurance cases, the dependability, the architecture, and the accountability.

So the plan is that with a dependable system through that assuredness, we can manage these large, complex systems much more easily.

Gardner: Allen, many of The Open Group activities have been focused at the enterprise architect or business architect levels. Also with these risk and security issues, you’re focusing at chief information security officers or governance, risk, and compliance (GRC), officials or administrators. It sounds as if the Dependability through Assuredness standard shoots a little higher. Is this something a board-level mentality or leadership should be thinking about, and is this something that reports to them?

Board-level issue

Brown: In an organization, risk is a board-level issue, security has become a board-level issue, and so has organization design and architecture. They’re all up at that level. It’s a matter of the fiscal responsibility of the board to make sure that the organization is sustainable, and to make sure that they’ve taken the right actions to protect their organization in the future, in the event of an attack or a failure in their activities.

The risks to an organization are financial and reputation, and those risks can be very real. So, yes, they should be up there. Interestingly, when we’re looking at areas like business architecture, sometimes that might be part of the IT function, but very often now we’re seeing as reporting through the business lines. Even in governments around the world, the business architects are very often reporting up to business heads.

Gardner: Here in Philadelphia, you’re focused on some industry verticals, finance, government, health. We had a very interesting presentation this morning by Dr. David Nash, who is the Dean of the Jefferson School of Population Health, and he had some very interesting insights about what’s going on in the United States vis-à-vis public policy and healthcare.

One of the things that jumped out at me was, at the end of his presentation, he was saying how important it was to have behavior modification as an element of not only individuals taking better care of themselves, but also how hospitals, providers, and even payers relate across those boundaries of their organization.

That brings me back to this notion that these standards are very powerful and useful, but without getting people to change, they don’t have the impact that they should. So is there an element that you’ve learned and that perhaps we can borrow from Dr. Nash in terms of applying methods that actually provoke change, rather than react to change?

Brown: Yes, change is a challenge for many people. Getting people to change is like taking a horse to water, but will it drink? We’ve got to find methods of doing that.

One of the things about The Open Group standards is that they’re pragmatic and practical standards. We’ve seen’ in many of our standards’ that where they apply to product or service, there is a procurement pull through. So the FACE Consortium, for example, a $30 billion procurement means that this is real and true.

In the case of healthcare, Dr. Nash was talking about the need for boundaryless information sharing across the organizations. This is a major change and it’s a change to the culture of the organizations that are involved. It’s also a change to the consumer, the patient, and the patient advocates.

All of those will change over time. Some of that will be social change, where the change is expected and it’s a social norm. Some of that change will change as people and generations develop. The younger generations are more comfortable with authority that they perceive with the healthcare professionals, and also of modifying the behavior of the professionals.

The great thing about the healthcare service very often is that we have professionals who want to do a number of things. They want to improve the lives of their patients, and they also want to be able to do more with less.

Already a need

There’s already a need. If you want to make any change, you have to create a need, but in healthcare, there is already a pent-up need that people see that they want to change. We can provide them with the tools and the standards that enable it to do that, and standards are critically important, because you are using the same language across everyone.

It’s much easier for people to apply the same standards if they are using the same language, and you get a multiplier effect on the rate of change that you can achieve by using those standards. But I believe that there is this pent-up demand. The need for change is there. If we can provide them with the appropriate usable standards, they will benefit more rapidly.

Gardner: Of course, measuring the progress with the standards approach helps as well. We can determine where we are along the path as either improvements are happening or not happening. It gives you a common way of measuring.

The other thing that was fascinating to me with Dr. Nash’s discussion was that he was almost imploring the IT people in the crowd to come to the rescue. He’s looking for a cavalry and he’d really seemed to feel that IT, the data, the applications, the sharing, the collaboration, and what can happen across various networks, all need to be brought into this.

How do we bring these worlds together? There is this policy, healthcare and population statisticians are doing great academic work, and then there is the whole IT world. Is this something that The Open Group can do — bridge these large, seemingly unrelated worlds?

Brown: At the moment, we have the capability of providing the tools for them to do that and the processes for them to do that. Healthcare is a very complex world with the administrators and the healthcare professionals. You have different grades of those in different places. Each department and each organization has its different culture, and bringing them together is a significant challenge.

In some of that processes, certainly, you start with understanding what it is you’re trying to address. You start with what are the pain points, what are the challenges, what are the blockages, and how can we overcome those blockages? It’s a way of bringing people together in workshops. TOGAF, a standard of The Open Group, has the business scenario method, bringing people together, building business scenarios, and understanding what people’s pain points are.

As long as we can then follow through with the solutions and not disappoint people, there is the opportunity for doing that. The reality is that you have to do that in small areas at a time. We’re not going to take the entire population of the United States and get everyone in the workshop and work altogether.

But you can start in pockets and then generate evangelists, proof points, and successful case studies. The work will then start emanating out to all other areas.

Gardner: It seems too that, with a heightened focus on vertical industries, there are lessons that could be learned in one vertical industry and perhaps applied to another. That also came out in some of the discussions around big data here at the conference.

The financial industry recognized the crucial role that data plays, made investments, and brought the constituencies of domain expertise in finance with the IT domain expertise in data and analysis, and came up with some very impressive results.

Do you see that what has been the case in something like finance is now making its way to healthcare? Is this an enterprise or business architect role that opens up more opportunity for those individuals as business and/or enterprise architects in healthcare? Why don’t we see more enterprise architects in healthcare?

Good folks

Brown: I don’t know. We haven’t run the numbers to see how many there are. There are some very competent enterprise architects within the healthcare industry around the world. We’ve got some good folks there.

The focus of The Open Group for the last couple of decades or so has always been on horizontal standards, standards that are applicable to any industry. Our focus is always about pragmatic standards that can be implemented and touched and felt by end-user consumer organizations.

Now, we’re seeing how we can make those even more pragmatic and relevant by addressing the verticals, but we’re not going to lose the horizontal focus. We’ll be looking at what lessons can be learned and what we can build on. Big data is a great example of the fact that the same kind of approach of gathering the data from different sources, whatever that is, and for mixing it up and being able to analyze it, can be applied anywhere.

The challenge with that, of course, is being able to capture it, store it, analyze it, and make some sense of it. You need the resources, the storage, and the capability of actually doing that. It’s not just a case of, “I’ll go and get some big data today.”

I do believe that there are lessons learned that we can move from one industry to another. I also believe that, since some geographic areas and some countries are ahead of others, there’s also a cascading of knowledge and capability around the world in a given time scale as well.

Gardner: Well great. I’m afraid we’ll have to leave it there. We’ve been talking about the increasingly essential role of standards in a complex world, where risk and dependability become even more essential. We have seen how The Open Group is evolving to meet these challenges through many of its activities and through many of the discussions here at the conference.

Please join me now in thanking our guest, Allen Brown, President and CEO of The Open Group. Thank you.

Brown: Thanks for taking the time to talk to us, Dana.

Comments Off

Filed under ArchiMate®, Business Architecture, Cloud, Conference, Enterprise Architecture, Healthcare, Open Platform 3.0, Professional Development, Service Oriented Architecture, TOGAF, TOGAF®

Speaking the Language of Business with TOGAF®

By Glenn Evans, Senior Consultant at Enterprise Architects

TOGAF-A-personal-journey

I remember as a young child coming from a ‘non-sports obsessed’ family, I didn’t know what a yorker was, didn’t know what ‘LBW’ meant, or why Dennis Lillee or Geoffrey Boycott were such legends. I was ill equipped to join in on those all-important schoolboy conversations – the Monday morning autopsy of the weekend’s sporting events. Similarly, 30 years later, enterprise architecture presented me with the same dilemma. 

I remember as a junior IT engineer, I’d hear the technology choice made by the customer was for ‘business reasons’, not what was logical in my technical view of the world. I now see ‘Architecture’ was influencing the project decisions, it was the source of the ‘business reasons’.

In my early days as an Architect, it was like being back at primary school; I struggled with the conversation. There was a level of assumed knowledge with respect to the conversation and the process that was not readily accessible to me. So, I learnt the long and hard way.

Fast forward a decade or so… As a mandatory requirement of my new role with Enterprise Architects I recently attended our TOGAF® training. To be honest, I anticipated another dry, idealistic framework that, whilst relevant to the work that I do, would probably not be all that practical and would be difficult to apply to a real world situation. How wrong was I?

Don’t misunderstand! The TOGAF® manual is dry! Yes it is “another framework” and yes you do need to tailor it to the situation you are in, but this is one of its greatest strengths, this is what makes it so flexible and therefore relevant and applicable to real world situations. But it’s not the framework itself that has me excited. It’s what it enables.

To me TOGAF®:

  • Is a common language, linking the discovery from each of the domains together and to the business requirements, across different levels of the business in an iterative process.
  • Provides a toolset to articulate the complex, simply. 
  • Provides a backstop, giving traceable, auditable decision support for those difficult conversations.
  • Allows the development of focused visual models of complex and disparate sets of data.

This was clearly demonstrated to me on a recent engagement. I was deep in thought, staring at a collection of printed Architecture Models displayed on a wall. One of the admin staff with no IT or business background asked me what “it all meant”. I spent a few minutes explaining that these were models of the business and the technology used in it. Not only did they immediately understand the overall concept of what they were looking at, they were actually able to start extracting real insights from the models.

In my mind, it doesn’t get any better than that. I wish I had known about TOGAF® a decade ago, I would have been a better architect – and a lot sooner.

Glenn EvansGlenn Evans is a Senior Consultant for Enterprise Architects and is based in Melbourne, Australia.

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

2 Comments

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

TOGAF® 9 Certification Growth – Number of Individuals Certified Increases in the Last 12 Months – Now Over 24,000

By Andrew Josey, The Open Group

The number of individuals certified in the TOGAF® 9 certification program as of July 1st 2013 was 23,800. This represents 9000 new certifications in the equivalent twelve month period. Today (22nd July 2013) the total number of certifications is 24,213.

TOGAF continues to be adopted globally with certified individuals from ninety-six different countries.

TOGAF cert 2013

The top five countries include UK, USA, Netherlands, Australia and India.

Individuals certified by Country – TOP 10 Countries – July 2013

Rank

# Individuals

Country

Percentage

1

3629

UK

15.32%

2

3058

USA

12.91%

3

2277

Netherlands

9.61%

4

1648

Australia

6.96%

5

1611

India

6.8%

6

1118

Canada

4.72%

7

949

South Africa

4.01%

8

819

France

3.46%

9

810

China

3.42%

10

796

Finland

3.36%

Individuals certified by Region – July 2013

cert-by-region

There are forty-eight TOGAF 9 training partners worldwide and fifty-six accredited TOGAF 9 courses.  More information on TOGAF 9 Certification, including the directory of Certified People and official accredited training course calendar, can be obtained from The Open Group website at: http://www.opengroup.org/togaf9/cert/.

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, Enterprise Architecture, TOGAF®

The Open Group Philadelphia – Day Three Highlights

By Loren K. Baynes, Director, Global Marketing Communications at The Open Group.

We are winding down Day 3 and gearing up for the next two days of training and workshops.  Today’s subject areas included TOGAF®, ArchiMate®, Risk Management, Innovation Management, Open Platform 3.0™ and Future Trends.

The objective of the Future Trends session was to discuss “emerging business and technical trends that will shape enterprise IT”, according to Dave Lounsbury, Chief Technical Officer of The Open Group.

This track also featured a presentation by Dr. William Lafontaine, VP High Performance Computing, Analytics & Cognitive Markets, IBM Research, who gave an overview of the “Global Technology Outlook 2013”.  He stated the Mega Trends are:  Growing Scale/Lower Barrier of Entry; Increasing Complexity/Yet More Consumable; Fast Pace; Contextual Overload.  Mike Walker, Strategies & Enterprise Architecture Advisor for HP, noted the key disrupters that will affect our future are the business of IT, technology itself, expectation of consumers and globalization.

The session concluded with an in-depth Q&A with Bill, Dave, Mike (as shown below) and Allen Brown, CEO of The Open Group.Philly Day 3

Other sessions included presentations by TJ Virdi (Senior Enterprise Architect, Boeing) on Innovation Management, Jack Jones (President, CXOWARE, Inc.) on Risk Management and Stephen Bennett (Executive Principal, Oracle) on Big Data.

A special thanks goes to our many sponsors during this dynamic conference: Windstream, Architecting the Enterprise, Metaplexity, BIZZdesign, Corso, Avolution, CXOWARE, Penn State – Online Program in Enterprise Architecture, and Association of Enterprise Architects.

Stay tuned for post-conference proceedings to be posted soon!  See you at our conference in London, October 21-24.

Comments Off

Filed under ArchiMate®, Conference, Cybersecurity, Data management, Enterprise Architecture, Enterprise Transformation, Open Platform 3.0, RISK Management, Security Architecture, Standards, TOGAF®

The Open Group Philadelphia – Day Two Highlights

By Loren K. Baynes, Director, Global Marketing Communications at The Open Group.

philly 2.jpgDay 2 at The Open Group conference in the City of Brotherly Love, as Philadelphia is also known, was another busy and remarkable day.

The plenary started with a fascinating presentation, “Managing the Health of the Nation” by David Nash, MD, MBA, Dean of Jefferson School of Population Health.  Healthcare is the number one industry in the city of Philadelphia, with the highest number of patients in beds in the top 10 US cities. The key theme of his thought-provoking speech was “boundaryless information sharing” (sound familiar?), which will enable a healthcare system that is “safe, effective, patient-centered, timely, equitable, efficient”.

Following Dr. Nash’s presentation was the Healthcare Transformation Panel moderated by Allen Brown, CEO of The Open Group.  Participants were:  Gina Uppal (Fulbright-Killam Fellow, American University Program), Mike Lambert (Open Group Fellow, Architecting the Enterprise), Rosemary Kennedy (Associate Professor, Thomas Jefferson University), Blaine Warkentine, MD, MPH and Fran Charney (Pennsylvania Patient Safety Authority). The group brought different sets of experiences within the healthcare system and provided reaction to Dr. Nash’s speech.  All agree on the need for fundamental change and that technology will be key.

The conference featured a spotlight on The Open Group’s newest forum, Open Platform 3.0™ by Dr. Chris Harding, Director of Interoperability.  Open Platform 3.0 was formed to advance The Open Group vision of Boundaryless Information Flow™ to help enterprises in the use of Cloud, Social, Mobile Computing and Big Data.  For more info; http://www.opengroup.org/getinvolved/forums/platform3.0

The Open Group flourishes because of people interaction and collaboration.  The accolades continued with several members being recognized for their outstanding contributions to The Open Group Trusted Technology Forum (OTTF) and the Service-Oriented Architecture (SOA) and Cloud Computing Work Groups.  To learn more about our Forums and Work Groups and how to get involved, please visit http://www.opengroup.org/getinvolved

Presentations and workshops were also held in the Healthcare, Finance and Government vertical industries. Presenters included Larry Schmidt (Chief Technologist, HP), Rajamanicka Ponmudi (IT Architect, IBM) and Robert Weisman (CEO, Build the Vision, Inc.).

2 Comments

Filed under ArchiMate®, Business Architecture, Cloud/SOA, Conference, Cybersecurity, Data management, Enterprise Architecture, Enterprise Transformation, Healthcare, O-TTF, Open Platform 3.0, Security Architecture, Standards, TOGAF®

Follow

Get every new post delivered to your Inbox.

Join 7,631 other followers

%d bloggers like this: