Category Archives: TOGAF

Open Platform 3.0™ to Help Rally Organizations in Innovation and Development

by Andy Mulholland, Former Global CTO, Capgemini

The Open Platform 3.0™ initiative, launched by The Open Group, provides a forum in which organizations, including standards bodies, as much as users and product vendors, can coordinate their approach to new business models and new practices for use of IT, can define or identify common vendor-neutral standards, and can foster the adoption of those standards in a cohesive and aligned manner to ensure a integrated commercial viable set of solutions.

The goal is to enable effective business architectures, that support a new generation of interoperable business solutions, quickly, and at low cost using new technologies and provisioning methods, but with integration to existing IT environments.

Acting on behalf of its core franchise base of CIOs, and in association with the US and European CIO associations, Open Platform 3.0 will act as a rallying point for all involved in the development of technology solutions that new innovative business models and practices require.

There is a distinctive sea change in the way that organizations are adopting and using a range of new technologies, mostly relating to a front office revolution in how business is performed with their customers, suppliers and even within their markets. More than ever The Open Group mission of Boundaryless Information Flow™ through the mutual development of technology standards and methods is relevant to this change.

The competitive benefits are driving rapid Business adoption but mostly through a series of business management owned and driven pilots, usually with no long term thought as to scale, compliance, security, even data integrity. Rightly the CIO is concerned as to these issues, but too often in the absence of experience in this new environment and the ability to offer constructive approaches these concerns are viewed as unacceptable barriers.

This situation is further enflamed by the sheer variety of products and different groups, both technological and business, to try to develop workable standards for particular elements. Currently there is little, if any, overall coordination and alignment between all of these individually valuable elements towards a true ‘system’ approach with understandable methods to deliver the comprehensive enterprise approach in a manner that will truly serve the full business purposes.

The business imperatives supported by the teaching of Business Schools are focused on time as a key issue and advocate small fast projects built on externally provisioned, paid for against use, cloud services.  These are elements of the sea change that have to be accepted, and indeed will grow as society overall expects to do business and obtain their own requirements in the same way.

Much of these changes are outside the knowledge, experience of often power of current IT departments, yet they rightly understand that to continue in their essential role of maintaining the core internal operations and commercial stability this change must introduce a new generation of deployment, integration, and management methods. The risk is to continue the polarization that has already started to develop between the internal IT operations based on Client-Server Enterprise Applications versus the external operations of sales and marketing using Browser-Cloud based Apps and Services.

At best this will result in an increasingly decentralized and difficult to manage business, at worst Audit and Compliance management will report this business as being in breach of financial and commercial rules. This is being recognized by organizations introducing a new type of role supported by Business Schools and Universities termed a Business Architect. Their role in the application of new technology is to determine how to orchestrate complex business processes through Big Data and Big Process from the ‘Services’ available to users. This is in many ways a direct equivalent, though with different skills, to an Enterprise Architect in conventional IT who will focus on the data integrity from designing Applications and their integration.

The Open Group’s massive experience in the development of TOGAF®, together with its wide spread global acceptability, lead to a deep understanding of the problem, the issues, and how to develop a solution both for Business Architecture, as well as for its integration with Enterprise Architecture.

The Open Group believes that it is uniquely positioned to play this role due to its extensive experience in the development of standards on behalf of user enterprises to enable Boundaryless Information Flow including its globally recognized Enterprise Architecture standard TOGAF. Moreover it believes from feedback received from many directions this move will be welcomed by many of those involved in the various aspects of this exciting period of change.

mulhollandAndy joined Capgemini in 1996, bringing with him thirteen years of experience from previous senior IT roles across all major industry sectors.

In his former role as Global Chief Technology Officer, Andy was a member of the Capgemini Group management board and advised on all aspects of technology-driven market changes, as well as serving on the technology advisory boards of several organizations and enterprises.

A popular speaker with many appearances at major events all around the World, and frequently quoted by the press, in 2009 Andy was voted one of the top 25 most influential CTOs in the world by InfoWorld USA, and in 2010 his CTOblog was voted best Blog for Business Managers and CIOs for the third third year running by Computing Weekly UK. Andy retired in June 2012, but still maintains an active association with the Capgemini Group and his activities across the Industry lead to his achieving 29th place in 2012 in the prestigious USA ExecRank ratings category ‘Top CTOs’.

Comments Off

Filed under Open Platform 3.0, 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®

The Open Group Conference to Emphasize Healthcare as Key Sector for Ecosystem-Wide Interactions

By Dana Gardner, Interarbor Solutions

Listen to the recorded podcast here

Dana Gardner: 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. Registration to the conference remains open. Follow the conference on Twitter at #ogPHL.

Gardner

I’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 a panel of experts to explore how new IT trends are empowering improvements, specifically in the area of healthcare. We’ll learn how healthcare industry organizations are seeking large-scale transformation and what are some of the paths they’re taking to realize that.

We’ll see how improved cross-organizational collaboration and such trends as big data and cloud computing are helping to make healthcare more responsive and efficient.

With that, please join me in welcoming our panel, Jason Uppal, Chief Architect and Acting CEO at clinicalMessage. Welcome, Jason.

Jason Uppal: Thank you, Dana.

Inside of healthcare and inside the healthcare ecosystem, information either doesn’t flow well or it only flows at a great cost.

Gardner: And we’re also joined by Larry Schmidt, Chief Technologist at HP for the Health and Life Sciences Industries. Welcome, Larry.

Larry Schmidt: Thank you.

Gardner: And also, Jim Hietala, Vice President of Security at The Open Group. Welcome back, Jim. [Disclosure: The Open Group and HP are sponsors of BriefingsDirect podcasts.]

Jim Hietala: Thanks, Dana. Good to be with you.

Gardner: Let’s take a look at this very interesting and dynamic healthcare sector, Jim. What, in particular, is so special about healthcare and why do things like enterprise architecture and allowing for better interoperability and communication across organizational boundaries seem to be so relevant here?

Hietala: There’s general acknowledgement in the industry that, inside of healthcare and inside the healthcare ecosystem, information either doesn’t flow well or it only flows at a great cost in terms of custom integration projects and things like that.

Fertile ground

From The Open Group’s perspective, it seems that the healthcare industry and the ecosystem really is fertile ground for bringing to bear some of the enterprise architecture concepts that we work with at The Open Group in order to improve, not only how information flows, but ultimately, how patient care occurs.

Gardner: Larry Schmidt, similar question to you. What are some of the unique challenges that are facing the healthcare community as they try to improve on responsiveness, efficiency, and greater capabilities?

Schmidt: There are several things that have not really kept up with what technology is able to do today.

For example, the whole concept of personal observation comes into play in what we would call “value chains” that exist right now between a patient and a doctor. We look at things like mobile technologies and want to be able to leverage that to provide additional observation of an individual, so that the doctor can make a more complete diagnosis of some sickness or possibly some medication that a person is on.

We want to be able to see that observation in real life, as opposed to having to take that in at the office, which typically winds up happening. I don’t know about everybody else, but every time I go see my doctor, oftentimes I get what’s called white coat syndrome. My blood pressure will go up. But that’s not giving the doctor an accurate reading from the standpoint of providing great observations.

Technology has advanced to the point where we can do that in real time using mobile and other technologies, yet the communication flow, that information flow, doesn’t exist today, or is at best, not easily communicated between doctor and patient.

There are plenty of places that additional collaboration and communication can improve the whole healthcare delivery model.

If you look at the ecosystem, as Jim offered, there are plenty of places that additional collaboration and communication can improve the whole healthcare delivery model.

That’s what we’re about. We want to be able to find the places where the technology has advanced, where standards don’t exist today, and just fuel the idea of building common communication methods between those stakeholders and entities, allowing us to then further the flow of good information across the healthcare delivery model.

Gardner: Jason Uppal, let’s think about what, in addition to technology, architecture, and methodologies can bring to bear here? Is there also a lag in terms of process thinking in healthcare, as well as perhaps technology adoption?

Uppal: I’m going to refer to a presentation that I watched from a very well-known surgeon from Harvard, Dr. Atul Gawande. His point was is that, in the last 50 years, the medical industry has made great strides in identifying diseases, drugs, procedures, and therapies, but one thing that he was alluding to was that medicine forgot the cost, that everything is cost.

At what price?

Today, in his view, we can cure a lot of diseases and lot of issues, but at what price? Can anybody actually afford it?

Uppal

His view is that if healthcare is going to change and improve, it has to be outside of the medical industry. The tools that we have are better today, like collaborative tools that are available for us to use, and those are the ones that he was recommending that we need to explore further.

That is where enterprise architecture is a powerful methodology to use and say, “Let’s take a look at it from a holistic point of view of all the stakeholders. See what their information needs are. Get that information to them in real time and let them make the right decisions.”

Therefore, there is no reason for the health information to be stuck in organizations. It could go with where the patient and providers are, and let them make the best decision, based on the best practices that are available to them, as opposed to having siloed information.

So enterprise-architecture methods are most suited for developing a very collaborative environment. Dr. Gawande was pointing out that, if healthcare is going to improve, it has to think about it not as medicine, but as healthcare delivery.

There are definitely complexities that occur based on the different insurance models and how healthcare is delivered across and between countries.

Gardner: And it seems that not only are there challenges in terms of technology adoption and even operating more like an efficient business in some ways. We also have very different climates from country to country, jurisdiction to jurisdiction. There are regulations, compliance, and so forth.

Going back to you, Larry, how important of an issue is that? How complex does it get because we have such different approaches to healthcare and insurance from country to country?

Schmidt: There are definitely complexities that occur based on the different insurance models and how healthcare is delivered across and between countries, but some of the basic and fundamental activities in the past that happened as a result of delivering healthcare are consistent across countries.

As Jason has offered, enterprise architecture can provide us the means to explore what the art of the possible might be today. It could allow us the opportunity to see how innovation can occur if we enable better communication flow between the stakeholders that exist with any healthcare delivery model in order to give us the opportunity to improve the overall population.

After all, that’s what this is all about. We want to be able to enable a collaborative model throughout the stakeholders to improve the overall health of the population. I think that’s pretty consistent across any country that we might work in.

Ongoing work

Gardner: Jim Hietala, maybe you could help us better understand what’s going on within The Open Group and, even more specifically, at the conference in Philadelphia. There is the Population Health Working Group and there is work towards a vision of enabling the boundaryless information flow between the stakeholders. Any other information and detail you could offer would be great.[Registration to the conference remains open. Follow the conference on Twitter at #ogPHL.]

Hietala: On Tuesday of the conference, we have a healthcare focus day. The keynote that morning will be given by Dr. David Nash, Dean of the Jefferson School of Population Health. He’ll give what’s sure to be a pretty interesting presentation, followed by a reactors’ panel, where we’ve invited folks from different stakeholder constituencies.

Hietala

We are going to have clinicians there. We’re going to have some IT folks and some actual patients to give their reaction to Dr. Nash’s presentation. We think that will be an interesting and entertaining panel discussion.

The balance of the day, in terms of the healthcare content, we have a workshop. Larry Schmidt is giving one of the presentations there, and Jason and myself and some other folks from our working group are involved in helping to facilitate and carry out the workshop.

The goal of it is to look into healthcare challenges, desired outcomes, the extended healthcare enterprise, and the extended healthcare IT enterprise and really gather those pain points that are out there around things like interoperability to surface those and develop a work program coming out of this.

We want to be able to enable a collaborative model throughout the stakeholders to improve the overall health of the population.

So we expect it to be an interesting day if you are in the healthcare IT field or just the healthcare field generally, it would definitely be a day well spent to check it out.

Gardner: Larry, you’re going to be talking on Tuesday. Without giving too much away, maybe you can help us understand the emphasis that you’re taking, the area that you’re going to be exploring.

Schmidt: I’ve titled the presentation “Remixing Healthcare through Enterprise Architecture.” Jason offered some thoughts as to why we want to leverage enterprise architecture to discipline healthcare. My thoughts are that we want to be able to make sure we understand how the collaborative model would work in healthcare, taking into consideration all the constituents and stakeholders that exist within the complete ecosystem of healthcare.

This is not just collaboration across the doctors, patients, and maybe the payers in a healthcare delivery model. This could be out as far as the drug companies and being able to get drug companies to a point where they can reorder their raw materials to produce new drugs in the case of an epidemic that might be occurring.

Real-time model

It would be a real-time model that allows us the opportunity to understand what’s truly happening, both to an individual from a healthcare standpoint, as well as to a country or a region within a country and so on from healthcare. This remixing of enterprise architecture is the introduction to that concept of leveraging enterprise architecture into this collaborative model.

Then, I would like to talk about some of the technologies that I’ve had the opportunity to explore around what is available today in technology. I believe we need to have some type of standardized messaging or collaboration models to allow us to further facilitate the ability of that technology to provide the value of healthcare delivery or betterment of healthcare to individuals. I’ll talk about that a little bit within my presentation and give some good examples.

It’s really interesting. I just traveled from my company’s home base back to my home base and I thought about something like a body scanner that you get into in the airport. I know we’re in the process of eliminating some of those scanners now within the security model from the airports, but could that possibly be something that becomes an element within healthcare delivery? Every time your body is scanned, there’s a possibility you can gather information about that, and allow that to become a part of your electronic medical record.

There is a lot of information available today that could be used in helping our population to be healthier.

Hopefully, that was forward thinking, but that kind of thinking is going to play into the art of the possible, with what we are going to be doing, both in this presentation and talking about that as part of the workshop.

Gardner: Larry, we’ve been having some other discussions with The Open Group around what they call Open Platform 3.0™, which is the confluence of big data, mobile, cloud computing, and social.

One of the big issues today is this avalanche of data, the Internet of things, but also the Internet of people. It seems that the more work that’s done to bring Open Platform 3.0 benefits to bear on business decisions, it could very well be impactful for centers and other data that comes from patients, regardless of where they are, to a medical establishment, regardless of where it is.

So do you think we’re really on the cusp of a significant shift in how medicine is actually conducted?

Schmidt: I absolutely believe that. There is a lot of information available today that could be used in helping our population to be healthier. And it really isn’t only the challenge of the communication model that we’ve been speaking about so far. It’s also understanding the information that’s available to us to take that and make that into knowledge to be applied in order to help improve the health of the population.

As we explore this from an as-is model in enterprise architecture to something that we believe we can first enable through a great collaboration model, through standardized messaging and things like that, I believe we’re going to get into even deeper detail around how information can truly provide empowered decisions to physicians and individuals around their healthcare.

So it will carry forward into the big data and analytics challenges that we have talked about and currently are talking about with The Open Group.

Healthcare framework

Gardner: Jason Uppal, we’ve also seen how in other business sectors, industries have faced transformation and have needed to rely on something like enterprise architecture and a framework like TOGAF® in order to manage that process and make it something that’s standardized, understood, and repeatable.

It seems to me that healthcare can certainly use that, given the pace of change, but that the impact on healthcare could be quite a bit larger in terms of actual dollars. This is such a large part of the economy that even small incremental improvements can have dramatic effects when it comes to dollars and cents.

So is there a benefit to bringing enterprise architect to healthcare that is larger and greater than other sectors because of these economics and issues of scale?

Uppal: That’s a great way to think about this thing. In other industries, applying enterprise architecture to do banking and insurance may be easily measured in terms of dollars and cents, but healthcare is a fundamentally different economy and industry.

It’s not about dollars and cents. It’s about people’s lives, and loved ones who are sick, who could very easily be treated, if they’re caught in time and the right people are around the table at the right time. So this is more about human cost than dollars and cents. Dollars and cents are critical, but human cost is the larger play here.

Whatever systems and methods are developed, they have to work for everybody in the world.

Secondly, when we think about applying enterprise architecture to healthcare, we’re not talking about just the U.S. population. We’re talking about global population here. So whatever systems and methods are developed, they have to work for everybody in the world. If the U.S. economy can afford an expensive healthcare delivery, what about the countries that don’t have the same kind of resources? Whatever methods and delivery mechanisms you develop have to work for everybody globally.

That’s one of the things that a methodology like TOGAF brings out and says to look at it from every stakeholder’s point of view, and unless you have dealt with every stakeholder’s concerns, you don’t have an architecture, you have a system that’s designed for that specific set of audience.

The cost is not this 18 percent of the gross domestic product in the U.S. that is representing healthcare. It’s the human cost, which is many multitudes of that. That’s is one of the areas where we could really start to think about how do we affect that part of the economy, not the 18 percent of it, but the larger part of the economy, to improve the health of the population, not only in the North America, but globally.

If that’s the case, then what really will be the impact on our greater world economy is improving population health, and population health is probably becoming our biggest problem in our economy.

We’ll be testing these methods at a greater international level, as opposed to just at an organization and industry level. This is a much larger challenge. A methodology like TOGAF is a proven and it could be stressed and tested to that level. This is a great opportunity for us to apply our tools and science to a problem that is larger than just dollars. It’s about humans.

All “experts”

Gardner: Jim Hietala, in some ways, we’re all experts on healthcare. When we’re sick, we go for help and interact with a variety of different services to maintain our health and to improve our lifestyle. But in being experts, I guess that also means we are witnesses to some of the downside of an unconnected ecosystem of healthcare providers and payers.

One of the things I’ve noticed in that vein is that I have to deal with different organizations that don’t seem to communicate well. If there’s no central process organizer, it’s really up to me as the patient to pull the lines together between the different services — tests, clinical observations, diagnosis, back for results from tests, sharing the information, and so forth.

Have you done any studies or have anecdotal information about how that boundaryless information flow would be still relevant, even having more of a centralized repository that all the players could draw on, sort of a collaboration team resource of some sort? I know that’s worked in other industries. Is this not a perfect opportunity for that boundarylessness to be managed?

Hietala: I would say it is. We all have experiences with going to see a primary physician, maybe getting sent to a specialist, getting some tests done, and the boundaryless information that’s flowing tends to be on paper delivered by us as patients in all the cases.

So the opportunity to improve that situation is pretty obvious to anybody who’s been in the healthcare system as a patient. I think it’s a great place to be doing work. There’s a lot of money flowing to try and address this problem, at least here in the U.S. with the HITECH Act and some of the government spending around trying to improve healthcare.

We’ll be testing these methods at a greater international level, as opposed to just at an organization and industry level.

You’ve got healthcare information exchanges that are starting to develop, and you have got lots of pain points for organizations in terms of trying to share information and not having standards that enable them to do it. It seems like an area that’s really a great opportunity area to bring lots of improvement.

Gardner: Let’s look for some examples of where this has been attempted and what the success brings about. I’ll throw this out to anyone on the panel. Do you have any examples that you can point to, either named organizations or anecdotal use case scenarios, of a better organization, an architectural approach, leveraging IT efficiently and effectively, allowing data to flow, putting in processes that are repeatable, centralized, organized, and understood. How does that work out?

Uppal: I’ll give you an example. One of the things that happens when a patient is admitted to hospital and in hospital is that they get what’s called a high-voltage care. There is staff around them 24×7. There are lots of people around, and every specialty that you can think of is available to them. So the patient, in about two or three days, starts to feel much better.

When that patient gets discharged, they get discharged to home most of the time. They go from very high-voltage care to next to no care. This is one of the areas where in one of the organizations we work with is able to discharge the patient and, instead of discharging them to the primary care doc, who may not receive any records from the hospital for several days, they get discharged to into a virtual team. So if the patient is at home, the virtual team is available to them through their mobile phone 24×7.

Connect with provider

If, at 3 o’clock in the morning, the patient doesn’t feel right, instead of having to call an ambulance to go to hospital once again and get readmitted, they have a chance to connect with their care provider at that time and say, “This is what the issue is. What do you want me to do next? Is this normal for the medication that I am on, or this is something abnormal that is happening?”

When that information is available to that care provider who may not necessarily have been part of the care team when the patient was in the hospital, that quick readily available information is key for keeping that person at home, as opposed to being readmitted to the hospital.

We all know that the cost of being in a hospital is 10 times more than it is being at home. But there’s also inconvenience and human suffering associated with being in a hospital, as opposed to being at home.

Those are some of the examples that we have, but they are very limited, because our current health ecosystem is a very organization specific, not  patient and provider specific. This is the area there is a huge room for opportunities for healthcare delivery, thinking about health information, not in the context of the organization where the patient is, as opposed to in a cloud, where it’s an association between the patient and provider and health information that’s there.

Extending that model will bring infinite value to not only reducing the cost, but improving the cost and quality of care.

In the past, we used to have emails that were within our four walls. All of a sudden, with Gmail and Yahoo Mail, we have email available to us anywhere. A similar thing could be happening for the healthcare record. This could be somewhere in the cloud’s eco setting, where it’s securely protected and used by only people who have granted access to it.

Those are some of the examples where extending that model will bring infinite value to not only reducing the cost, but improving the cost and quality of care.

Schmidt: Jason touched upon the home healthcare scenario and being able to provide touch points at home. Another place that we see evolving right now in the industry is the whole concept of mobile office space. Both countries, as well as rural places within countries that are developed, are actually getting rural hospitals and rural healthcare offices dropped in by helicopter to allow the people who live in those communities to have the opportunity to talk to a doctor via satellite technologies and so on.

The whole concept of a architecture around and being able to deal with an extension of what truly lines up being telemedicine is something that we’re seeing today. It would be wonderful if we could point to things like standards that allow us to be able to facilitate both the communication protocols as well as the information flows in that type of setting.

Many corporations can jump on the bandwagon to help the rural communities get the healthcare information and capabilities that they need via the whole concept of telemedicine.

That’s another area where enterprise architecture has come into play. Now that we see examples of that working in the industry today, I am hoping that as part of this working group, we’ll get to the point where we’re able to facilitate that much better, enabling innovation to occur for multiple companies via some of the architecture or the architecture work we are planning on producing.

Single view

Gardner: It seems that we’ve come a long way on the business side in many industries of getting a single view of the customer, as it’s called, the customer relationship management, big data, spreading the analysis around among different data sources and types. This sounds like a perfect fit for a single view of the patient across their life, across their care spectrum, and then of course involving many different types of organizations. But the government also needs to have a role here.

Jim Hietala, at The Open Group Conference in Philadelphia, you’re focusing on not only healthcare, but finance and government. Regarding the government and some of the agencies that you all have as members on some of your panels, how well do they perceive this need for enterprise architecture level abilities to be brought to this healthcare issue?

Hietala: We’ve seen encouraging signs from folks in government that are encouraging to us in bringing this work to the forefront. There is a recognition that there needs to be better data flowing throughout the extended healthcare IT ecosystem, and I think generally they are supportive of initiatives like this to make that happen.

Gardner: Of course having conferences like this, where you have a cross pollination between vertical industries, will perhaps allow some of the technical people to talk with some of the government people too and also have a conversation with some of the healthcare people. That’s where some of these ideas and some of the collaboration could also be very powerful.

We’ve seen encouraging signs from folks in government that are encouraging to us in bringing this work to the forefront.

I’m afraid we’re almost out of time. We’ve been talking about an interesting healthcare transition, moving into a new phase or even era of healthcare.

Our panel of experts have been looking at some of the trends in IT and how they are empowering improvement for how healthcare can be more responsive and efficient. And we’ve seen how healthcare industry organizations can take large scale transformation using cross-organizational collaboration, for example, and other such tools as big data, analytics, and cloud computing to help solve some of these issues.

This special BriefingsDirect discussion comes to you in conjunction with The Open Group Conference this July in Philadelphia. Registration to the conference remains open. Follow the conference on Twitter at #ogPHL, and you will hear more about healthcare or Open Platform 3.0 as well as enterprise transformation in the finance, government, and healthcare sectors.

With that, I’d like to thank our panel. We’ve been joined today by Jason Uppal, Chief Architect and Acting CEO at clinicalMessage. Thank you so much, Jason.

Uppal: Thank you, Dana.

Gardner: And also Larry Schmidt, Chief Technologist at HP for the Health and Life Sciences Industries. Thanks, Larry.

Schmidt: You bet, appreciate the time to share my thoughts. Thank you.

Gardner: And then also Jim Hietala, Vice President of Security at The Open Group. Thanks so much.

Hietala: Thank you, Dana.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator throughout these thought leader interviews. Thanks again for listening and come back next time.

Comments Off

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

Enterprise Architecture in China: Who uses this stuff?

by Chris Forde, GM APAC and VP Enterprise Architecture, The Open Group

Since moving to China in March 2010 I have consistently heard a similar set of statements and questions, something like this….

“EA? That’s fine for Europe and America, who is using it here?”

“We know EA is good!”

“What is EA?”

“We don’t have the ability to do EA, is it a problem if we just focus on IT?”

And

“Mr Forde your comment about western companies not discussing their EA programs because they view them as a competitive advantage is accurate here too, we don’t discuss we have one for that reason.” Following that statement the lady walked away smiling, having not introduced herself or her company.

Well some things are changing in China relative to EA and events organized by The Open Group; here is a snapshot from May 2013.

M GaoThe Open Group held an Enterprise Architecture Practitioners Conference in Shanghai China May 22nd 2013. The conference theme was EA and the spectrum of business value. The presentations were made by a mix of non-member and member organizations of The Open Group, most but not all based in China. The audience was mostly non-members from 55 different organizations in a range of industries. There was a good mix of customer, supplier, government and academic organizations presenting and in the audience. The conference proceedings are available to registered attendees of the conference and members of The Open Group. Livestream recordings will also be available shortly.

Organizations large and small presented about the fact that EA was integral to delivering business value. Here’s the nutshell.

China

Huawei is a leading global ICT communications provider based in Shenzhen China.  They presented on EA applied to their business transformation program and the ongoing development of their core EA practice.

GKHB is a software services organization based in Chengdu China. They presented on an architecture practice applied to real time forestry and endangered species management.

Nanfang Media is a State Owned Enterprise, the second largest media organization in the country based in Guangzhou China. They presented on the need to rapidly transform themselves to a modern integrated digital based organization.

McKinsey & Co a Management Consulting company based in New York USA presented an analysis of a CIO survey they conducted with Peking University.

Mr Wang Wei a Partner in the Shanghai office of McKinsey & Co’s Business Technology Practice reviewed a survey they conducted in co-operation with Peking University.

wang wei.jpg

The Survey of CIO’s in China indicated a common problem of managing complexity in multiple dimensions: 1) “Theoretically” Common Business Functions, 2) Across Business Units with differing Operations and Product, 3) Across Geographies and Regions. The recommended approach was towards “Organic Integration” and to carefully determine what should be centralized and what should be distributed. An Architecture approach can help with managing and mitigating these realities. The survey also showed that the CIO’s are evenly split amongst those dedicated to a traditional CIO role and those that have a dual Business and CIO role.

Mr Yang Li Chao Director of EA and Planning at Huawei and Ms Wang Liqun leader of the EA Center of Excellence at Huawei yang li chao.jpgwang liqun.jpgoutlined the 5-year journey Huawei has been on to deal with the development, maturation and effectiveness of an Architecture practice in a company that has seen explosive growth and is competing on a global scale. They are necessarily paying a lot of attention to Talent Management and development of their Architects, as these people are at the forefront of the company Business Transformation efforts. Huawei constantly consults with experts on Architecture from around the world and incorporates what they consider best practice into their own method and framework, which is based on TOGAF®.

 Mr He Kun CIO of Nanfang Media described the enormous pressures his traditional media organization is under, such as a concurrent loss of advertising and talent to digital media.

he kun.jpgHe gave and example where China Mobile has started its own digital newspaper leveraging their delivery platform. So naturally, Nanfang media is also undergoing a transformation and is looking to leverage its current advantages as a trusted source and its existing market position. The discipline of Architecture is a key enabler and aids as a foundation for clearly communicating a transformation approach to other business leaders. This does not mean using EA Jargon but communicating in the language of his peers for the purpose of obtaining funding to accomplish the transformation effectively.

Mr Chen Peng Vice General Manager of GKHB Chengdu described the use of an Architecture approach to managing precious national resources such as forestry, bio diversity and endangered species. He descrichen peng.jpgbed the necessity for real time information in observation, tracking and responses in this area and the necessity of “Informationalization” of Forestry in China as a part of eGovernment initiatives not only for the above topics but also for the countries growth particularly in supplying the construction industry. The Architecture approach taken here is also based on TOGAF®.

The take away from this conference is that Enterprise Architecture is alive and well amongst certain organizations in China. It is being used in a variety of industries.  Value is being realized by executives and practitioners, and delivered for both IT and Business units. However for many companies EA is also a new idea and to date its value is unclear to them.

The speakers also made it clear that there are no easy answers, each organization has to find its own use and value from Enterprise Architecture and it is a learning journey. They expressed their appreciation that The Open Group and its standards are a place where they can make connections, pull from and contribute to in regards to Enterprise Architecture.

Comments Off

Filed under Enterprise Architecture, Enterprise Transformation, Professional Development, Standards, TOGAF, TOGAF®, Uncategorized

What is Business Architecture? Part 2

By Allen Brown, President and CEO, The Open Group

I recently wrote that I had 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.

The initial summary (blog) of the responses I received was focused on the feedback from Business Architects who were employed by organizations I think of as consumers; this one is focused on the feedback from consultants, ranging from those who are working on their own to others who are working with some of the largest consulting firms that we know.

Why I chose the countries I did and the questions I asked are contained in that earlier blog.

Again the responses have been amazing and thank you to everyone who took the time to do so.  They included some wonderful insights into their role and into their beliefs with respect to Business Architecture.

Summarizing the feedback from the consultants is even more difficult than that of the consumers.  Understandably, each of them has their own approach.  I have found it very difficult to decide what to leave out in order to get this down to a reasonable length for a blog.

It is important to repeat 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.

The first point of note from the responses is that Business Architecture is still evolving and finding its place in the enterprise.  While the consumers saw it as somewhere between immature and missing in action, the consultants tended to look at the how and why of its evolution.  In one case the view was that Business Architecture is evolving in response to a demand for greater business oriented control over transformation, while another reported, disappointedly, that business architecture is often seen as Business Process Review/Improvement on steroids.  Other comments included:

  • Generally Business Architecture is seen as business process review and/or business process improvement. There is not much real Business Architecture going on at the moment.
  • It is not widely understood at this point in time.  This first initiative will be conducted in a lightweight manner to gain the business buy in and get some projects onto the roadmap.  Delivery time will be a key factor in prioritization as we will be looking for some projects with shorter duration and lower complexity so some tangible benefits can be realized
  • It is not formally recognized.  Last year I was in the supply chain team (who also deal with Lean and other operational improvement skills).  We have Business Analysts, and a People and Change Team.  We have several areas than do Operating Models.  To me various elements of these would be included under the Business Architecture banner.

In common with the consumer viewpoint, the focus of Business Architecture is on the “What”.  Some of the comments included:

  • The Business Architecture will exist with or without technology, but as soon as technology is involved, the technology exists to service the business architecture, and the business architecture should be the input to the technology and application architecture.
  • Make recommendations of what projects the business should perform, in addition to relevant and timely corrections to the governance structure, business processes, and the structure of business information
  • The business architecture I am referring to is not the traditional element of the IT based Enterprise Architecture, but a framework that is totally business oriented and in which the whole business, including IT, can commit to in order to truly understand their problems and most of all the potential to genuinely improve the business.
  • “Business Architecture is not about telling people how to do their job at a detail level. Its function is to help us all to understand how together we can achieve the business goals and objectives
  • The primary focus of the Business Architect includes the analysis of business motivations and business operations, through the use of business analysis frameworks and related networks that link these aspects of the enterprise together. The Business Architect works to develop an integrated view of the business unit, in the context of the enterprise, using a repeatable approach, cohesive framework, and available industry standard techniques.

In some cases the focus of activity was the entire enterprise: the CEO view.  In others it was at the line of business or business unit level.  In all cases the focus was very much on the business issues:

  • Strategy
  • Business goals, objectives and drivers
  • Business operating model
  • Organization structure
  • Functions, roles, actors
  • Business processes
  • Key data elements

Being able to see the big picture and have the ability to communicate with key stakeholders was emphasized time and again.

  • Make it relevant and “makes sense” to senior management, operations and IT groups.  Visualize problems; have a way to communicate with the business team
  • Be able to relate – what big decision we need to make and to package it up so that execs can make a decision
  • The only person who cares about the whole picture is the CEO.  BA provides the CEO with a one page picture of the whole enterprise in a logical fashion
  • Show the CEO where impact is on a page – give confidence – control.  Help him make decisions around priorities.
  • The secret of good architecture is taking all the complexity and presenting it in a simplistic way that anyone can understand on a ‘need to know’ basis and quickly find the right answer to the current and/or planned state of business components.
  • BA facilitates strategic consistency with the business.  Where do we need to differentiate more than others?  How do we build in once or move to one instance?
  • Drive prioritization of when to invest based on the businesses strategic goals
  • Distil, communicate and relate to a business person
  • A key purpose of this new business driven architecture is to provide the means for communicating and controlling the strategic and operational intentions of the business in a way that is easy to understand for everyone in the organization

A common feature in the feedback is that underneath the models the information is rich – enables drill down – traceability to underlying requirements linked to the requirements.

Two areas of activity stood out the most: Capabilities and Value Streams.  Both of these are focused on WHAT a company needs to be able to do to execute its business strategy and to bring a product or service to a consumer.  Comments included:

  • Capabilities – combination of people, process and technology to deliver product features
  • Logical building blocks – gather information and compare the level of maturity in each capability, compare with others, understand where could we go to
  • Define/ champion 1 common reference model / capability model / logical building blocks of the enterprise.
  • Establish Capability, Information maps, Value Streams, stages and business processes.
  • Have intimate knowledge of the Business Capability (As Is/To Be), Business Component Structure, Business Processes, Value Streams and Conceptual Business Models.
  • Have the capability picture
  • … not only the capability of each component but also the relationship between components from every appropriate perspective (purpose, technical, compliance, risk, acceptability, etc.)
  • The Business Architecture is the first stage in a broader EA initiative.  Subsequent phases will align capabilities to applications and look at the major data flows between those applications

Since value stream mapping is a lean manufacturing technique, lean techniques are also called out as being relevant to business architecture because they identify areas of waste, which often change work processes or procedures, which may or may not impact applications and technology.  Feedback included:

  • Each value steam has Inputs (that triggers the value stream) and Outputs (the value based result of completing the business activities).
  • Each value stream is designed against Critical Success Factors, founded on the strategic intentions and priorities of the business, that represent the required business performance with Time, Cost, Quality, Risk and Compliance.
    • Time – How long the process should take from a Customer Perspective
    • Cost – How much the process should cost, measured using for example TDABC (Time Driven Activity Based Costing)
    • Quality – A statement clearly describing the (fit for) purpose of the activity
    • Risk – The protected acceptable residual risk involved due to effective control within the proposed design
    • Compliance – The specific interpreted requirements placed on the activity by interpreting the obligations of associated legislation and regulations.
    • Value streams are directed or informed by policies, plans, procedures, governance, regulations, business rules and other guidance, and are enabled by roles, IT Systems and other resources that will directly or indirectly support their completion.
    • The As-Is Architecture consists of the related value streams, indicating how the business is currently performing.   Under the facilitation of the business architect, design teams investigate how these can be improved to produce the Target State version of the Value Stream.

It was argued that displaying the relationship between the guidance, the enablers and the value streams, opens up the potential to discuss many things related to the business performance; that this alignment is critical for ensuring the business functions operate as expected; and that this is the major feature of business architecture and provides answers to so many previously unanswered questions for business managers.

Incidentally, since value stream maps are often drawn by hand in pencil (to keep the mapping process real-time, simple and iterative by allowing for simple correction) this tends to reinforce the comment by one of the consumer respondents that his most useful tools are pencil and paper.

The role and relationship of Business Architects, Business Analysts and other folk that might come under the general heading of Enterprise Architecture, varied from one organization to another, often seemingly dependent upon the size of the consulting firm.  At different ends of the spectrum were:

  • To a greater or lesser extent, Business Architects are supported by Business Analysts (“the knowledge processing factory) and by people with deep skills in design and process, Lean, 6 Sigma, HR, organization design and training.  The Business Architects ensure that all of the pieces fit together in a logical manor and that the impact can be shown in dollar terms
  • The Enterprise Architect is a person who can perform as both Solution Architect (SA) and a Business Architect (as needed) and has some ability as an Information Architect. In addition, an EA can perform at an enterprise level, something that is NOT required of either an SA or BA

The feedback on the title of Enterprise Architect was as varied as the number of responses.  The comments included:

  • Enterprise Architecture seen as a bad word
  • With hindsight, referring to it as architecture was a mistake
  • Enterprise Architecture is an IT version of technical specifications and drawings and not architecture, as such, and Enterprise Architects are mainly focused on the Application and Technology areas.
  • I think the technology story wave is coming to an end.  The focus will be more on the BusArch and InfoArch as that is where, in my view, the business IP sits. In the future more Bus/Info architects will become Enterprise WIDE architects, not so much enterprise architects

In most cases but not all, there is no such job as an Enterprise Architect.  It is in instead the overall term for Business Architects, Solution Architects, Information Architects, Value architects, Journey architects and so on.

The key differences that were highlighted between the roles of Business Architect and Enterprise Architect was a matter of depth and potentially also of education:

  • Enterprise Architects will tend to have more depth in technology; Business Architects will tend to have more depth in business techniques
  • Enterprise Architects will tend to have a Computer Science degree, or similar; Business Architects will tend to have a business degree or experience.

It was also stated that Business Architecture is a logical growth path for an experienced Business Analyst provided they get an Enterprise level understanding of the Business and Architecture.

When I actually look at the background of the respondents, I can see experience in:

  • IT consulting
  • Operations management
  • Product management
  • Project management
  • Business Analyst
  • Aeronautical Engineering
  • Logistics
  • … and much more besides

and education backgrounds are similarly varied.

The common theme is a deep interest in the business issues and what makes organizations work.

The evolution of Business Architecture clearly has a long way to go and depends upon the ability of the practitioners to relate to the business leaders.  One respondent predicted a shift and a segmentation in these comments:

  • For business that serve the “mum and dads”. I believe you will see a grouping of the different architectures based upon the business objectives and capabilities.
  • I think the technology story wave is coming to an end.  The focus will be more on the BusArch and InfoArch as that is where, in my view, the business IP sits. Applications and Technologies are all COTS nowadays (unless you are developing them). I think in the future more Bus/Info architects will become Enterprise WIDE Architects, not so much Enterprise Architects

The last word goes to the feedback that one Business Architect reported:

“In my time with this amazing new methodology I have had two separate reactions that stand out:

The first from an Acting CEO that was one of the biggest sceptics when I started the initiative and in admitting he had been, said that he owed me a big apology that he found the Business Architecture to be both highly useful and quite remarkable.

The second was in relation to a BPO initiative for a long standing traditional finance industry organization, when the chairman of the board said it [Business Architecture] had made a major decision relatively easy, that would have otherwise been one of the most difficult in the company‘s history.”

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.

4 Comments

Filed under Business Architecture, Certifications, Enterprise Architecture, Enterprise Transformation, Professional Development, 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

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

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

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

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®

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

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

Security and Cloud Computing Themes to be explored at The Open Group San Francisco Conference

By The Open Group Conference Team

Cybersecurity and Cloud Computing are two of the most pressing trends facing enterprises today. The Open Group Conference San Francisco will feature tracks on both trends where attendees can learn about the latest developments in both disciplines as well as hear practical advice for implementing both secure architectures and for moving enterprises into the Cloud.  Below are some of the highlights and featured speakers from both tracks.

Security

The San Francisco conference will provide an opportunity for practitioners to explore the theme of “hacktivism,” the use and abuse of IT to drive social change, and its potential impact on business strategy and Enterprise Transformation.  Traditionally, IT security has focused on protecting the IT infrastructure and the integrity of the data held within.  However, in a rapidly changing world where hacktivism is an enterprise’s biggest threat, how can enterprise IT security respond?

Featured speakers and panels include:

  • Steve Whitlock, Chief Security Strategist, Boeing, “Information Security in the Internet Age”
  • Jim Hietala, Vice President, Security, The Open Group, “The Open Group Security Survey Results”
  • Dave Hornford, Conexiam, and Chair, The Open Group Architecture Forum, “Overview of TOGAF® and SABSA® Integration White Paper”
  • Panel – “The Global Supply Chain: Presentation and Discussion on the Challenges of Protecting Products Against Counterfeit and Tampering”

Cloud Computing

According to Gartner, Cloud Computing is now entering the “trough of disillusionment” on its hype cycle. It is critical that organizations better understand the practical business, operational and regulatory issues associated with the implementation of Cloud Computing in order to truly maximize its potential benefits.

Featured speakers and panels include:

  • David JW Gilmour, Metaplexity Associates, “Architecting for Information Security in a Cloud Environment”
  • Chris Lockhart, Senior Enterprise Architect, UnitedHeal, “Un-Architecture: How a Fortune 25 Company Solved the Greatest IT Problem”
  • Penelope Gordon, Cloud and Business Architect, 1Plug Corporation, “Measuring the Business Performance of Cloud Products”
  • Jitendra Maan, Tata Consultancy, “Mobile Intelligence with Cloud Strategy”
  • Panel – “The Benefits, Challenges and Survey of Cloud Computing Interoperability and Portability”
    • Mark Skilton, Capgemini; Kapil Bakshi, Cisco; Jeffrey Raugh, Hewlett-Packard

Please join us in San Francisco for these speaking tracks, as well as those on our featured them of Enterprise Transformation and the role of enterprise architecture. For more information, please go to the conference homepage: http://www3.opengroup.org/sanfrancisco2012

2 Comments

Filed under Cloud, Cloud/SOA, Cybersecurity, Information security, Security Architecture, Semantic Interoperability, TOGAF

Why do pencils have erasers?

By Andrew Josey and Garry Doherty, The Open Group

We know that TOGAF® isn’t perfect. In fact, it probably never will be, but sometimes, especially after a major release, it’s a good idea to stop and look backwards after its been in implementation for a while… just to make sure we’ve gotten it right and to review the standard for reasons of further clarification and to improve consistency.

That’s why we’re releasing TOGAF® 9.1. It contains a set of corrections to address comments raised since the introduction of TOGAF® 9 in 2009. We have been able to address over 400 of the comments received against TOGAF® 9, resulting in over 450 changes to the standard.

The maintenance updates in TOGAF® 9.1 are based on feedback received on the framework as organizations have put it to good use over the past three years. As such the changes are upwards compatible adding clarification, consistency and additional detail where needed. Some of the most significant updates include:

  • The SOA chapter (Part III, Chapter 22, Using TOGAF to Define & Govern SOAs) has been updated to include the latest Open Group SOA Work Group output providing guidance on adapting the ADM phases for SOA
  • ADM Phases E and F (Part II, Chapters 13 and 14) have been reworked to match the level of detail in other phases, and the uses of terminology for Transition Architecture, Roadmap, and Implementation Strategy clarified and made consistent
  • Corrections have been applied to aspects of the Content Metamodel (Part IV, Chapter 34, The Content Metamodel) including the metamodel diagrams
  • The concepts of levels, iterations and partitions have been clarified and made consistent. This includes a reorganization of material in Part III, Chapter 19, Applying Iteration to the ADM and Chapter 20, Applying the ADM across the Architecture Landscape, and also Part V, Chapter 40, Architecture Partitioning
  • The terms “artifact” versus “viewpoint” have been clarified and made consistent. This includes a restructuring of Part IV, Chapter 35, Architectural Artifacts
  • Changes have been made to improve general usability including:
    • The artifacts for each phase are now listed in the phase descriptions
    • Duplicate text in several places has been replaced with an appropriate reference
    • The “Objectives” sections of the phases have been reworked
    • Some artifacts have been renamed to better reflect their usage

If you’re already TOGAF® 9 certified,  don’t worry about the status of your certification. The TOGAF® 9 Certification for People Program has been designed to accommodate maintenance updates to the TOGAF® 9 standard such as TOGAF® 9.1. So impacts on the program are minimal:

  • The two levels of certification remain as TOGAF® 9 Foundation and TOGAF® 9 Certified.
  • Individuals who are currently certified in the TOGAF® 9 People Certification program remain certified.

TOGAF 9.1 is available for online reading at http://www.opengroup.org/togaf/ and available in The Open Group Bookstore at http://www.opengroup.org/bookstore/catalog/g116.htm .

A detailed description of the changes between TOGAF 9 and TOGAF 9.1 is available at http://www.opengroup.org/bookstore/catalog/u112.htm .

So now you know why pencils have erasers… because perfection is a constantly moving target!

5 Comments

Filed under Enterprise Architecture, Standards, TOGAF, TOGAF®

“Making Standards Work®”

By Andrew Josey, The Open Group

Next month as part of the ongoing process of “Making Standards Work®,” we will be setting standards and policy with those attending the member meetings at The Open Group Conference, London, (May 9-12, Central Hall Westminster). The standards development activities include a wide range of subject areas from Cloud Computing, Tools and People certification, best practices for Trusted Technology, SOA and Quantum Lifecycle Management, as well as maintenance of existing standards such as TOGAF® and ArchiMate®. The common link with all these activities is that all of these are open standards developed by members of The Open Group.

Why do our members invest their time and efforts in development of open standards? The key reasons as I see them are as follows:

  1. Open standards are a core part of today’s infrastructure
  2. Open standards allow vendors to differentiate their offerings by offering a level of openness (portable interfaces and interoperability)
  3. Open standards establish a baseline from which competitors can innovate
  4. Open standards backed with certification enable customers to buy with increased confidence

This is all very well, you say — but what differentiates The Open Group from other standards organizations? Well, when The Open Group develops a new standard, we take an end-to-end view of the ecosystem all the way through from customer requirements, developing consensus standards to certification and procurement. We aim to deliver standards that meet a need in the marketplace and then back those up with certification that delivers an assurance about the products or in the case of people certification, their knowledge or skills and experience. We then take regular feedback on our standards, maintain them and evolve them according to marketplace needs. We also have a deterministic, timely process for developing our standards that helps to avoid the stalemate that can occur in some standards development.

Let’s look briefly at two of the most well known Open Group standards:  UNIX® and TOGAF®,. The UNIX® and TOGAF® standards are both examples of where a full ecosystem has been developed around the standard.

The UNIX® standard for operating systems has been around since 1995 and is now in its fourth major iteration. High reliability, availability and scalability are all attributes associated with certified UNIX® systems. As well as the multi-billion-dollar annual market in server systems from HP, Oracle, IBM and Fujitsu, there is an installed base of 50 million users* using The Open Group certified UNIX® systems on the desktop.

TOGAF® is the standard enterprise architecture method and framework. It encourages use with other frameworks and adoption of best practices for enterprise architecture. Now in its ninth iteration, it is freely available for internal use by any organization globally and is widely adopted with over 60% of the Fortune 50 and more than 80% of the Global Forbes 50. The TOGAF® certification program now has more than 15,000 certified individuals, including over 6,000 for TOGAF® 9.

If you are able to join us in London in May, I hope you will be able to also join us at the member meetings to continue making standards work. If you are not yet a member then I hope you will attend the conference itself and network with the members to find out more and consider joining us in Making Standards Work®!

For more information on The Open Group Standards Process visit http://www.opengroup.org/standardsprocess/

(*) Apple estimated number from Briefing October 2010. Mac OS X is certified to the UNIX 03 standard.

Standards development will be part of member meetings taking place at The Open Group Conference, London, May 9-13. Join us for best practices and case studies on Enterprise Architecture, Cloud, Security and more, presented by preeminent thought leaders in the industry.

Andrew Josey is Director of Standards within The Open Group, responsible for the Standards Process across the organization. Andrew leads the standards development activities within The Open Group Architecture Forum, including the development and maintenance of TOGAF® 9, and the TOGAF® 9 People certification program. He also chairs the Austin Group, the working group responsible for development and maintenance the POSIX 1003.1 standard that forms the core volumes of the Single UNIX® Specification. He is the ISO project editor for ISO/IEC 9945 (POSIX). He is a member of the IEEE Computer Society’s Golden Core and is the IEEE P1003.1 chair and the IEEE PASC Functional chair of Interpretations. Andrew is based in the UK.

Comments Off

Filed under Standards, TOGAF, UNIX

Follow

Get every new post delivered to your Inbox.

Join 7,149 other followers

%d bloggers like this: