Category Archives: TOGAF

Driving Boundaryless Information Flow in Healthcare

By E.G. Nadhan, HP

I look forward with great interest to the upcoming Open Group conference on EA & Enterprise Transformation in Finance, Government & Healthcare in Philadelphia in July 2013. In particular, I am interested in the sessions planned on topics related to the Healthcare Industry. This industry is riddled with several challenges of uncontrolled medical costs, legislative pressures, increased plan participation, and improved longevity of individuals. Come to think of it, these challenges are not that different from those faced when defining a comprehensive enterprise architecture. Therefore, can the fundamental principles of Enterprise Architecture be applied towards the resolution of these challenges in the Healthcare industry? The Open Group certainly thinks so.

Enterprise Architecture is a discipline, methodology, and practice for translating business vision and strategy into the fundamental structures and dynamics of an enterprise at various levels of abstraction. As defined by TOGAF®, enterprise architecture needs to be developed through multiple phases. These include Business Architecture, Applications, Information, and Technology Architecture. All this must be in alignment with the overall vision. The TOGAF Architecture Development Method enables a systematic approach to addressing these challenges while simplifying the problem domain.

This approach to the development of Enterprise Architecture can be applied towards the complex problem domain that manifests itself in Healthcare. Thus, it is no surprise that The Open Group is sponsoring the Population Health Working Group, which has a vision to enable “boundary-less information flow” between the stakeholders that participate in healthcare delivery. Checkout the presentation delivered by Larry Schmidt, Chief Technologist, Health and Life Sciences Industries, HP, US at the Open Group conference in Philadelphia.

As a Platinum member of The Open Group, HP has co-chaired the release of multiple standards, including the first technical cloud standard. The Open Group is also leading the definition of the Cloud Governance Framework. Having co-chaired these projects, I look forward to the launch of the Population Health Working Group with great interest.

Given the role of information in today’s landscape, “boundary-less information flow” between the stakeholders that participate in healthcare delivery is vital. At the same time, how about injecting a healthy dose of innovation given that enterprise Architects are best positioned for innovation – a post triggered by Forrester Analyst Brian Hopkins’s thoughts on this topic. The Open Group — with its multifaceted representation from a wide array of enterprises — provides incredible opportunities for innovation in the context of the complex landscape of the healthcare industry. Take a look at the steps taken by HP Labs to innovate and improve patient care one day at a time.

I would strongly encourage you to attend Schmidt’s session, as well as the Healthcare Transformation Panel moderated by Open Group CEO, Allen Brown at this conference.

How about you? What are some of the challenges that you are facing within the Healthcare industry today? Have you applied Enterprise Architecture development methods to problem domains in other industries? Please let me know.

Connect with Nadhan on: Twitter, Facebook, Linkedin and Journey Blog.

A version of this blog post originally appeared on the HP Enterprise Services Blog.

HP Distinguished Technologist and Cloud Advisor, E.G.Nadhan has over 25 years of experience in the IT industry across the complete spectrum of selling, delivering and managing enterprise level solutions for HP customers. He is the founding co-chair for The Open Group SOCCI project and is also the founding co-chair for the Open Group Cloud Computing Governance project. 

Leave a Comment

Filed under Business Architecture, Cloud, Cloud/SOA, Conference, Enterprise Architecture, Healthcare, 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.

Leave a Comment

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.

Leave a Comment

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

Corso Introduces Roadmapping Support for TOGAF® 9 in its Strategic Planning Platform

By Martin Owen, CEO, Corso

Last week, we announced new roadmapping support for TOGAF® in IBM Rational System Architect®, a leading Enterprise Architecture and modeling software.

The new TOGAF extension supports the modeling, migration and implementation of an Enterprise Architecture within Corso’s Strategic Planning Platform, which integrates Enterprise Architecture, IT planning and strategic planning into a single, comprehensive solution. The new TOGAF extension provides capabilities in managing current and future state architectures, work packages and timelines/lifecycles /heatmaps—key areas for successful roadmapping and transition planning.

Corso now offers roadmapping solutions for both ArchiMate® 2.0 and TOGAF as part of its Strategic Planning Platform. Both solutions are available as SaaS option, on-premise or standard perpetual license solution. A roadmapping datasheet and white paper are available.

Roadmapping is critical for building change-tolerant Enterprise Architectures that accurately describe and manage strategic business transformations. Our new solution gives Enterprise Architects the tools within TOGAF to more quickly map out a transition plan with deliverables for the organization. By tying plans to the business strategy, the architects can drive a faster development and implementation lifecycle.

Our new TOGAF solution offers these key capabilities:

  • Automatic generation of timeline diagrams with milestones and dimensions.
  • Work package definitions and resources so users can group and track specific actions.
  • Heat maps that display a visual map of the state of the business and IT infrastructure and highlight cost overruns.
  • Improved gap analysis through enhanced support for plateaus and gaps.
  • Roadmap reports that enable users to see the current and future states of the architecture and work packages.
  • Integration with IBM Rational Focal Point® so that work packages and milestones can be used in portfolio management and prioritization initiatives.
  • Lifecycle support for standard states such as application portfolio management.

Corso’s Strategic Planning Platform is a comprehensive solution that integrates Enterprise Architecture, IT and strategic planning into a fully charged change process that uses cloud technology to elevate decision-making to a strategic level. This approach unites business and architecture views into one central platform and leverages existing tools and the Web to share information and decision-making across various teams within the organization. For more information about Corso and its roadmapping solutions, visit http://www.corso.co.uk.

owen_martin

Martin Owen, CEO, Corso has spent over 20 years in Enterprise Architecture and is a co-author of the original Business Process Modeling Notation (BPMN) standard. Martin has run teams driving the product directions, strategies and roadmaps for the Enterprise Architecture tools at IBM.

Leave a Comment

Filed under Enterprise Architecture, TOGAF®, ArchiMate®

The Open Group Speakers Discuss Enterprise Architecture, Business Architecture and Enterprise Transformation

By Dana Gardner, Interarbor Solutions

Listen to the recorded podcast here: Expert Panel Explores Enterprise Architecture and Business Architecture as Enterprise Transformation Agents, or read the transcript 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 April 15, in Sydney, Australia.

I’m Dana Gardner, Principal Analyst at Interarbor Solutions, and I’ll be your host and moderator throughout these business transformation discussions. The conference, The Open Group’s first in Australia, will focus on “How Does Enterprise Architecture Transform an Enterprise?” And there will be special attention devoted to how enterprise transformation impacts such vertical industries as finance and defense, as well as exploration, mining, and minerals. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

We’re here now with two of the main speakers at the conference — Hugh Evans, the Chief Executive Officer of Enterprise Architects, a specialist enterprise architecture (EA) firm based in Melbourne, Australia; and Craig Martin, Chief Operations Officer and Chief Architect at Enterprise Architects.

As some background, Hugh is both the founder and CEO at Enterprise Architects. His professional experience blends design and business, having started out in traditional architecture, computer games design, and digital media, before moving into enterprise IT and business transformation.
In 1999, Hugh founded the IT Strategy Architecture Forum, which included chief architects from most of the top 20 companies in Australia. He has also helped found the Australian Architecture Body  of Knowledge and the London Architecture Leadership Forum in the UK.

Since starting Enterprise Architects in 2002, Hugh has grown the team to more than 100 people, with offices in Australia, the UK, and the U.S.
With a career spanning more than 20 years, Craig has held executive positions in the communications, high tech, media, entertainment, and government markets and has operated as an Enterprise Architect and Chief Consulting Architect for a while.

In 2012, Craig became COO of Enterprise Architects to improve the global scalability of the organization, but he is also a key thought leader for strategy and architecture practices for all their clients and also across the EA field.

Craig has been a strong advocate of finding differentiation in businesses through identifying new mixes of business capabilities in those organizations. He advises that companies that do not optimize how they reassemble their capabilities will struggle, and he also believes that business decision making should be driven by economic lifecycles.

So welcome to you both. How are you doing?

Hugh Evans: Great, Dana. Good morning, Dana. Welcome everyone. Craig Martin: Thanks very much for having us.

Big-picture perspective

Gardner: I look forward to our talk. Let’s look at this first from a big-picture perspective and then drill down into what you are going to get into at the conference in a couple of weeks. What are some of the big problems that businesses are facing, that they need to solve, and that architecture-level solutions can really benefit them. I’ll open this up to both Hugh and Craig?

Evans: Thanks very much, Dana. I’ll start with the trend in the industry around fast-paced change and disruptive innovation. You’ll find that many organizations, many industries, at the moment in the U.S., Australia, and around the world are struggling with the challenges of how to reinvent themselves with an increasing number of interesting and innovative business models coming through. For many organizations, this means that they need to wrap their arms around an understanding of their current business activities and what options they’ve got to leverage their strategic advantages.

We’re seeing business architecture as a tool for business model innovation, and on the other side, we’re also seeing business architecture as a tool that’s being used to better manage risk, compliance, security, and new technology trends around things like cloud, big data, and so on.

Martin: Yes, there is a strong drive within the industry to try and reduce complexity.  As organizations are growing, the business stakeholders are confronted with a large amount of information, especially within the architecture space. We’re seeing that they’re struggling with this complexity and have to make accurate and efficient business decisions on all this information.

What we are seeing, and based upon what Hugh has already discussed, is that some of those industry drivers are around disruptive business models. For example, we’re seeing it with the likes of higher education, the utility space, and financial services space, which are the dominant three.
There is a lot of change occurring in those spaces, and businesses are looking for ways to make them more agile to adapt to that change, and looking towards disciplined architecture and the business-architecture discipline to try and help them in that process.

Gardner: I think I know a bit about how we got here — computing, globalization, outsourcing, companies expanding across borders, the ability to enter new markets freely, and dealing with security, but also great opportunity. Did I miss anything? Is there anything about the past 10 or 15 years in business practices that have led now to this need for a greater emphasis on that strategic architectural level of thinking?

Martin: A lot has to do with basically building blocks. We’ve seen a journey that’s travelled within the architecture disciplines specifically. We call it the commodification of the business, and we’ve seen that maturity in the IT space. A lot of processes that used to be innovative in our business are now becoming fairly utility and core to the business. In any Tier 1 organization, a lot of the processes that used to differentiate them are now freely available in a number of vendor platforms, and any of their competitors can acquire those.

Looking for differentiation

So they are looking for that differentiation, the ability to be able to differentiate themselves from their competitors, and away from that sort of utility space. That’s a shift that’s beginning to occur. Because a lot of those IT aspects have become industrialized, that’s also moving up into the business space.

In other words, how can we now take complex mysteries in the business space and codify them? In other words, how can we create building blocks for them, so that organizations now can actually effectively work with those building blocks and string them together in different ways to solve more complex business problems.

Evans: I’ll add to that Dana. EA is now around 30 years old, but the rise in EA has really come from the need for IT systems to interoperate and to create common standards and common understanding within an organization for how an IT estate is going to come together and deliver the right type of business value.

Through the ’90s we saw the proliferation of technologies as a result of the extension of distributed computing models and the emergence of the Internet. We’ve seen now the ubiquity of the Internet and technology across business. The same sort of concepts that ring true in technology architecture extend out into the business, around how the business interoperates with its components.

The need to change very fast for business, which is occurring now in the current economy, with the entrepreneurship and the innovation going on, is seeing this type of thinking come to the fore. This type of thinking enables organizations to change more rapidly. The architecture itself won’t make the organization change rapidly, but it will provide the appropriate references and enable people to have the right conversations to make that happen.

Gardner: So architecture can come as a benefit when the complexity kicks in. When you try to change an organization, you don’t get lost along the way. Give me a sense about what sort of paybacks your clients get when they do this correctly, and what happens when you don’t do this very well?

Evans: Business architecture, as well as strategic architecture, is still quite a nascent capability for organizations, and many organizations are really still trying to get a grip on this. The general rule is that organizations don’t manage this so well at the moment, but organizations are looking to improving in this area, because of the obvious, even heuristic, payoffs that you get from being better organized.

You end up spending less money, because you’re a more efficient organization, and you end up delivering better value to customers, because you’re a more effective organization. This efficiency and effectiveness need within organizations is worth the price of investment in this area.
The actual tangible benefits that we’re seeing across our customers includes reduced cost of their IT estate.

Meeting profiles

You have improved security and improved compliance, because organizations can see where their capabilities are meeting the various risk and compliance profiles, and you are also seeing organizations bring products to market quicker. The ability to move through the product management process, bring products to market more rapidly, and respond to customer need more rapidly puts organizations in front and makes them more competitive.

The sorts of industries we’re seeing acting in this area would include the postal industry, where they are moving from a traditional mail- to parcels, which is a result of a move towards online retailing. You’re also seeing it in the telco sector and you’re seeing it in the banking and finance sector.
In the banking and finance sector, we’ve also seen a lot of this investment driven by the merger and acquisition (M&A) activity that’s come out of the financial crisis in various countries where we operate. These organizations are getting real value from understanding where the enterprise boundaries are, how they bring the business together, how they better integrate the organizations and acquisitions, and how they better divest.

Martin: We’re seeing, especially at the strategic level, that the architecture discipline is able to give business decision makers a view into different strategic scenarios. For example, where a number of environmental factors and market pressures would have been inputs into a discussion around how to change a business, we’re also seeing business decision makers getting a lot of value from running those scenarios through an actual hypothesis of the business model.

For example, they could be considering four or five different strategic scenarios, and what we are seeing is that, using the architecture discipline, it’s showing them effectively what those scenarios look like as they cascade through the business. It’s showing the impact on capabilities, on people and the approaches and technologies, and the impact on capital expenditures (CAPEX) and operational expenditures (OPEX). Those views of each of those strategic scenarios allows them to basically pull the trigger on the better strategic scenario to pursue, before they’ve invested all of their efforts and all that analysis to possibly get to the point where it wasn’t the right decision in the first place. So that might be referred to as sort of the strategic enablement piece.

We’re also seeing a lot of value for organizations within the portfolio space. We traditionally get questions like, “I have 180 projects out there. Am I doing the right things? Are those the right 180 projects, and are they going to help me achieve the types of CAPEX and OPEX reductions that I am looking for?”

With the architecture discipline, you don’t take a portfolio lens into what’s occurring within the business. You take an architectural lens, and you’re able to give executives an overview of exactly where the spend is occurring. You give them an overview of where the duplication is occurring, and where the loss of cohesion is occurring.

Common problems

A common problem we find, when we go into do these types of gigs, is the amount of duplication occurring across a number of projects. In a worst-case scenario, 75 percent of the projects are all trying to do the same thing, on the same capability, with the same processes.
So there’s a reduction of complexity and the production of efforts that’s occurring across the organizations to try and bring it and get it into more synergistic sessions.

We’re also seeing a lot of value occurring up at the customer experience space. That is really taking a strong look at this customer experience view, which is less around all of the underlying building blocks and capabilities of an organization and looking more at what sort of experiences we want to give our customer? What type of product offerings must we assemble, and what underlying building blocks of the organization must be assembled to enable those offerings and those value propositions?

That sort of traceability through the cycle gives you a view of what levers you must pull to optimize your customer experience. Organizations are seeing a lot of value there and that’s basically increasing their effectiveness in the market and having a direct impact on their market share.
And that’s something that we see time and time again, regardless of what the driver was behind the investment in the architecture project, seeing the team interact and build a coalition for action and for change. That’s the most impressive thing that we get to see.

Gardner: Let’s drill down a little bit into some of what you’ll be discussing at the conference in Sydney in April. One of the things that’s puzzling to me, when I go to these Open Group Conferences, is to better understand the relationship between business architecture and IT architecture and where they converge and where they differ. Perhaps you could offer some insights and maybe tease out what some discussion points for that would be at the conference.

Martin: That’s actually quite a hot topic. In general, the architecture discipline has grown from the IT space, and that’s a good progression for it to take, because we’re seeing the fruits of that discipline in how they industrialize IT components. We’re seeing the fruits of that in complex enterprise resource planning (ERP) systems, the modularization of those ERP systems, their ability to be customized, and adapt to businesses. It’s a fairly mature space, and the natural progression of that is to apply those same thinking patterns back up into the business space.

In order for this to work effectively well, when somebody asks a question like that, we normally respond with a “depends” statement. We have in this organization a thing called the mandate curve, and it relates to what the mandate is within the business. What is the organization looking to solve?

Are they looking to build an HR management system? Are they looking to gain efficiencies from an enterprise-wide ERP solution? Are they looking to reduce the value chain losses that they’re having on a monthly basis? Are they looking to improve customer experience across a group of companies? Or are they looking to improve shareholder value across the organization for an M&A, or maybe reduce cost-to-income.

Problem spaces

Those are some of the problem spaces, and we often get into that mind space to ask, “Those are the problems that you are solving, but what mandate is given to architecture to solve them?” We often find that the mandate for the IT architecture space is sitting beneath the CIO, and the CIO tends to use business architecture as a communication tool with business. In other words, to understand business better, to begin to apply architecture rigor to the business process.

Evans: It’s interesting, Dana. I spent a lot of time last year in the UK, working with the team across a number of business-architecture requirements. We were building business-architecture teams. We were also delivering some projects, where the initial investigation was a business- architecture piece, and we also ran some executive roundtables in the UK.

One thing that struck me in that investigation was the separation that existed in the business- architecture community from the traditional enterprise and technology architecture or IT architecture communities in those organizations that we were dealing with.
One insurance company, in particular, that was building a business-architecture team was looking for people that didn’t necessarily have an architecture background, but possibly could apply that insight. They were looking for deep business domain knowledge inside the various aspects of the insurance organization that they were looking to cover.

So to your question about the relationship between business architecture and IT architecture, where they converge and how they differ, it’s our view that business architecture is a subset of the broader EA picture and that these are actually integrated and unified disciplines.
However, in practice you’ll find that there is often quite a separation between these two groups. I think that the major reason for that is that the drivers that are actually creating the investment for business architecture are actually now from coming outside of IT, and to some extent, IT is replicating that investment to build the engagement capability to engage with business so that they can have a more strategic discussion, rather than just take orders from the business.

I think that over this year, we’re going to see more convergence between these two groups, and that’s certainly something that we are looking to foster in EA.

Gardner: I just came back from The Open Group Conference in California a few weeks ago, where the topic was focused largely on big data, but analysis was certainly a big part of that. Now, business analysis and business analysts, I suppose, are also part of this ecosystem. Are they subsets of the business architect? How do you see the role of business analysts now fitting into this, given the importance of data and the ability for organizations to manage data with new efficiency and scale?

Martin: Once again, that’s also a hot topic. There is a convergence occurring, and we see that across the landscape, when it comes to the number of frameworks and standards that people certify on. Ultimately, it comes to this knife-edge point, in which we need to interact with the business stakeholder and we need to elicit requirements from that stakeholder and be able to model them successfully.
The business-analysis community is slightly more mature in this particular space. They have, for example, the Business Analysis Body of Knowledge (BABOK). Within that space, they leverage a competency model, which in effect goes through a cycle, from an entry level BA, right up to what they refer to as the generalist BA, which is where they see the start of the business- architecture role.

Career path

There’s a career path from a traditional business analyst role, which is around requirements solicitation and requirements management, which seems to be quite project focused. In other words, dropping down onto project environments, understanding stakeholder needs and requirements, and modeling those and documenting them, helping the IT teams model the data flows, the data structures but with a specific link into the business space.

As you move up that curve, you get into the business-architecture space, which is a broader structural view around how all the building blocks fit together. In other words, it’s a far broader view than what the business analyst traditional part would take, and looks at a number of different domains. The business architect tends to focus a lot on, as you mentioned, the information space, and we see a difference between the information and the data space.

So the business architect is looking at performance, market-related aspects, and customer, information, as well as the business processes and functional aspects of an organization. You can see that the business analysts could almost be seen as the soldiers of these types of functions. In other words, they’re the guys that are in the trenches seeing what’s working on a day-to-day basis. They’ve got a number of tools that they’re equipped with, which for example the BABOK has given them. And there are all different ways and techniques that they are using to elicit those requirements from various business stakeholders, until they move out that curve up into the business architecture and strategic architecture space.

Evans: There’s an interesting pattern that I’ve noticed with the business-analyst-to-business- architecture career journey and the traditional IT track, where you see a number of people move into solution architect roles. There might be a solution architect on a project, they might move to multiple projects and ultimately do a program, and a number of those people then pop out to a much broader enterprise view, as they go through their career.

The business analyst is, in many respects, tracking that journey, where business analysts might focus on a project and requirements for a project, might look across at a high view, and possibly get to a point where they have a strong domain understanding that can drive high level sort of strategic discussions within the organization.

There is certainly a pattern emerging, and there are great opportunities for business analysts to come across into the architecture sphere. However, I believe that the broader EA discipline does need to make the effort to bridge that gap. Architecture needs to come across and find those connection points with the analyst community and help to elevate and converge the two sides.

Gardner: Craig, in your presentation at The Open Group Conference in Sydney, what do you hope to accomplish, and will this issue of how the business analyst fits in be prominent in that?

Martin: It’s a general theme that we’re using leading right up to the conference. We have a couple of webinars, which deal specifically with this topic. That’s leading up to the plenary talk at The Open Group Conference, which is really looking at how we can use these tools of the architecture discipline to be able to achieve the types of outcomes that we’ve spoken about here.

Building cohesion

In other words, how do I build cohesion in an organization? How do I look at different types of scenarios that I can execute against? What are the better ways to assemble all the efforts in my organization to achieve those outcomes? That’s taking us through a variety of examples that will be quite visual.

We’ll also be addressing the specific role of where we see the career path and the complementary nature of the business analyst and business architect, as they travel through the cycle of trying to operate at a strategic level and as a strategic enabler within the organization.

Gardner: Maybe you could also help me better understand something. When organizations decide that this is the right thing for them — as you mentioned earlier, this is still somewhat nascent — what are some good foundational considerations to get started? What needs to be put in place? Maybe it’s a mindset. How do you often find that enterprises get beyond the inertia and into this discussion about architecture and about the strategic benefits of it?

Martin: Once again, it’s a “depends” answer. For example, we often have two market segments, where a Tier 1 type company would want to build the capability themselves. So there’s a journey that we need to take them on around how to have a business-architecture capability while delivering the actual outcomes?

Tier 2 and Tier 3 clients often don’t necessarily want to build that type of capability, so we would focus directly on the outcomes. And those outcomes start with two views. Traditionally, we’re seeing the view driven almost on a bottom-up view, as the sponsors of these types of exercises try to get credibility within the organization.

That relates to helping the clients build what we refer to as the utility of the business-architecture space. Our teams go in and, in effect, build a bunch of what we refer to as anchor models to try and get a consistent representation of the business and a consistent language occurring across the entire enterprise, not just within a specific project.

And that gives them a common language they can talk about, for example, common capabilities and common outcomes that they’re looking to achieve. In other words, it’s not just a bunch of building blocks, but the actual outcome of each of those building blocks and how does it match something like a business-motivation model.

They also look within each of those building blocks to see what the resources are that creates each of those building blocks — things like people, process and tools. How do we mix those resources in the right way to achieve those types of outcomes that the business is looking for? Normally, the first path that we go through is to try to get that sort of consistent language occurring within an organization. As an organization matures, that artifact starts to lose its value, and we then find that, because it has created a consistent language in the organization, you can now overlay a variety of different types of views to give business people insights. Ultimately, they don’t necessarily want all these models, but they actually want insight into their organizations to enable them to make decisions.

We can overlay objectives, current project spend, CAPEX, and OPEX. We can overlay where duplication is occurring, where overspend is occurring, where there’s conflict occurring at a global scale around duplication of efforts, and with the impact of costs and reduction and efficiencies, all of those types of questions can be answered by merely overlaying a variety of views across this common language.

Elevating the value

That starts to elevate the value of these types of artifacts, and we start to see our business sponsors walking into meetings with all of these overlays on them, and having conversations between them and their colleagues, specifically around the insights that are drawn from these artifacts. We want the architecture to tell the story, not necessarily lengthy PowerPoint presentations, but as people are looking at these types of artifacts, they are actually seeing all the insights that come specifically from it.

The third and final part is often around the business getting to a level of maturity, in that they’re starting to use these types of artifacts and then are looking for different ways that they can now mix and assemble. That’s normally a sign of a mature organization and the business-architecture practice.

They have the building blocks. They’ve seen the value or the types of insights that they can provide. Are there different ways that I can string together my capabilities to achieve different outcomes? Maybe I have got different critical success factors that I am looking to achieve. Maybe there are new shift or new pressures coming in from the environment. How can I assemble the underlying structures of my organization to better cope with it? That’s the third phase that we take customers through, once they get to that level of maturity.

Evans: Just to add to that, Dana, I agree with Craig on the point that, if you show the business what can actually be delivered such as views on a page that elicit the right types of discussions and that demonstrate the issues, when they see what they’re going to get delivered, typically the eyes light up and they say, “I want one of those things.”

The thing with architecture that I have noticed over the years is that architecture is done by a lot of very intelligent people, who have great insights and great understanding, but it’s not just enough to know the answer. You have to know how to engage somebody with the material. So when the architecture content that’s coming through is engaging, clear, understandable, and can be consumed by a variety of stakeholders, they go, “That’s what I want. I want one of those.”

So my advice to somebody who is going down this path is that if they want to get support and sponsorship for this sort of thing, make sure they get some good examples of what gets delivered when it’s done well, as that’s a great way to actually get people behind it.

Gardner: I’m afraid we will have to leave it there. We’ve been talking with Hugh Evans, the CEO of Enterprise Architects, a specialist EA firm in Melbourne; and Craig Martin, the COO and Chief Architect at Enterprise Architects. Thanks to you both.

Evans: Thanks very much Dana, it has been a pleasure.

Martin: Thank you, Dana.

Gardner: This BriefingsDirect discussion comes to you in conjunction with The Open Group Conference, the first in Australia, on April 15 in Sydney. The focus will be on “How Does Enterprise Architecture Transform an Enterprise?”

So thanks again to both Hugh and Craig, and I know they will be joined by many more thought leaders and speakers on the EA subject and other architecture issues at the conference, and I certainly encourage our readers and listeners to attend that conference, if they’re in the Asia- Pacific region.

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

1 Comment

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

Complexity from Big Data and Cloud Trends Makes Architecture Tools like ArchiMate and TOGAF More Powerful, Says Expert Panel

By Dana Gardner, Interarbor Solutions

Listen to the recorded podcast here: Complexity from Big Data and Cloud Trends Makes Architecture Tools like ArchiMate and TOGAF More Powerful, Says Expert Panel, or read the transcript here.

We recently assembled a panel of Enterprise Architecture (EA) experts to explain how such simultaneous and complex trends as big data, Cloud Computing, security, and overall IT transformation can be helped by the combined strengths of The Open Group Architecture Framework (TOGAF®) and the ArchiMate® modeling language.

The panel consisted of Chris Forde, General Manager for Asia-Pacific and Vice President of Enterprise Architecture at The Open Group; Iver Band, Vice Chair of The Open Group ArchiMate Forum and Enterprise Architect at The Standard, a diversified financial services company; Mike Walker, Senior Enterprise Architecture Adviser and Strategist at HP and former Director of Enterprise Architecture at DellHenry Franken, the Chairman of The Open Group ArchiMate Forum and Managing Director at BIZZdesign, and Dave Hornford, Chairman of the Architecture Forum at The Open Group and Managing Partner at Conexiam. I served as the moderator.

This special BriefingsDirect thought leadership interview series comes to you in conjunction with The Open Group Conference recently held in Newport Beach, California. The conference focused on “Big Data – he transformation we need to embrace today.” [Disclosure: The Open Group and HP are sponsors ofBriefingsDirect podcasts.]

Here are some excerpts:

Gardner: Is there something about the role of the enterprise architect that is shifting?

Walker: There is less of a focus on the traditional things we come to think of EA such as standards, governance and policies, but rather into emerging areas such as the soft skills, Business Architecture, and strategy.

To this end I see a lot in the realm of working directly with the executive chain to understand the key value drivers for the company and rationalize where they want to go with their business. So we’re moving into a business-transformation role in this practice.

At the same time, we’ve got to be mindful of the disruptive external technology forces coming in as well. EA can’t just divorce from the other aspects of architecture as well. So the role that enterprise architects play becomes more and more important and elevated in the organization.

Two examples of this disruptive technology that are being focused on at the conference are Big Data and Cloud Computing. Both are providing impacts to our businesses not because of some new business idea but because technology is available to enhance or provide new capabilities to our business. The EA’s still do have to understand these new technology innovations and determine how they will apply to the business.

We need to get really good enterprise architects, it’s difficult to find good ones. There is a shortage right now especially given that a lot of focus is being put on the EA department to really deliver sound architectures.

Not standalone

Gardner: We’ve been talking a lot here about Big Data, but usually that’s not just a standalone topic. It’s Big Data and Cloud, Cloud, mobile and security.

So with these overlapping and complex relationships among multiple trends, why is EA and things like the TOGAF framework and the ArchiMate modeling language especially useful?

Band: One of the things that has been clear for a while now is that people outside of IT don’t necessarily have to go through the technology function to avail themselves of these technologies any more. Whether they ever had to is really a question as well.

One of things that EA is doing, and especially in the practice that I work in, is using approaches like the ArchiMate modeling language to effect clear communication between the business, IT, partners and other stakeholders. That’s what I do in my daily work, overseeing our major systems modernization efforts. I work with major partners, some of which are offshore.

I’m increasingly called upon to make sure that we have clear processes for making decisions and clear ways of visualizing the different choices in front of us. We can’t always unilaterally dictate the choice, but we can make the conversation clearer by using frameworks like the TOGAF standard and the ArchiMate modeling language, which I use virtually every day in my work.

Hornford: The fundamental benefit of these tools is the organization realizing its capability and strategy. I just came from a session where a fellow quoted a Harvard study, which said that around a third of executives thought their company was good at executing on its strategy. He highlighted that this means that two-thirds are not good at executing on their strategy.

If you’re not good at executing on your strategy and you’ve got Big Data, mobile, consumerization of IT and Cloud, where are you going? What’s the correct approach? How does this fit into what you were trying to accomplish as an enterprise?

An enterprise architect that is doing their job is bringing together the strategy, goals and objectives of the organization. Also, its capabilities with the techniques that are available, whether it’s offshoring, onshoring, Cloud, or Big Data, so that the organization is able to move forward to where it needs to be, as opposed to where it’s going to randomly walk to.

Forde: One of the things that has come out in several of the presentations is this kind of capability-based planning, a technique in EA to get their arms around this thing from a business-driver perspective. Just to polish what Dave said a little bit, it’s connecting all of those things. We see enterprises talking about a capability-based view of things on that basis.

Gardner: Let’s get a quick update. The TOGAF framework, where are we and what have been the highlights from this particular event?

Minor upgrade

Hornford: In the last year, we’ve published a minor upgrade for TOGAF version 9.1 which was based upon cleaning up consistency in the language in the TOGAF documentation. What we’re working on right now is a significant new release, the next release of the TOGAF standard, which is dividing the TOGAF documentation to make it more consumable, more consistent and more useful for someone.

Today, the TOGAF standard has guidance on how to do something mixed into the framework of what you should be doing. We’re peeling those apart. So with that peeled apart, we won’t have guidance that is tied to classic application architecture in a world of Cloud.

What we find when we have done work with the Banking Industry Architecture Network (BIAN) for banking architecture, Sherwood Applied Business Security Architecture (SABSA) for security architecture, and the TeleManagement Forum, is that the concepts in the TOGAF framework work across industries and across trends. We need to move the guidance into a place so that we can be far nimbler on how to tie Cloud with my current strategy, how to tie consumerization of IT with on-shoring?

Franken: The ArchiMate modeling language turned two last year, and the ArchiMate 1.0 standard is the language to model out the core of your EA. The ArchiMate 2.0 standard added two specifics to it to make it better aligned also to the process of EA.

According to the TOGAF standard, this is being able to model out the motivation, why you’re doing EA, stakeholders and the goals that drive us. The second extension to the ArchiMate standard is being able to model out its planning and migration.

So with the core EA and these two extensions, together with the TOGAF standard process working, you have a good basis on getting EA to work in your organization.

Gardner: Mike, fill us in on some of your thoughts about the role of information architecture vis-à-vis the larger business architect and enterprise architect roles.

Walker: Information architecture is an interesting topic in that it hasn’t been getting a whole lot of attention until recently.

Information architecture is an aspect of Enterprise Architecture that enables an information strategy or business solution through the definition of the company’s business information assets, their sources, structure, classification and associations that will prescribe the required application architecture and technical capabilities.

Information architecture is the bridge between the Business Architecture world and the application and technology architecture activities.

The reason I say that is because information architecture is a business-driven discipline that details the information strategy of the company. As we know, and from what we’ve heard at the conference keynotes like in the case of NASA, Big Data, and security presentations, the preservation and classification of that information is vital to understanding what your architecture should be.

Least matured

From an industry perspective, this is one of the least matured, as far as being incorporated into a formal discipline. The TOGAF standard actually has a phase dedicated to it in data architecture. Again, there are still lots of opportunities to grow and incorporate additional methods, models and tools by the enterprise information management discipline.

Enterprise information management not only it captures traditional topic areas like master data management (MDM), metadata and unstructured types of information architecture but also focusing on the information governance, and the architecture patterns and styles implemented in MDM, Big Data, etc. There is a great deal of opportunity there.

From the role of information architects, I’m seeing more and more traction in the industry as a whole. I’ve dealt with an entire group that’s focused on information architecture and building up an enterprise information management practice, so that we can take our top line business strategies and understand what architectures we need to put there.

This is a critical enabler for global companies, because oftentimes they’re restricted by regulation, typically handled at a government or regional area. This means we have to understand that we build our architecture. So it’s not about the application, but rather the data that it processes, moves, or transforms.

Gardner: Up until not too long ago, the conventional thinking was that applications generate data. Then you treat the data in some way so that it can be used, perhaps by other applications, but that the data was secondary to the application.

But there’s some shift in that thinking now more toward the idea that the data is the application and that new applications are designed to actually expand on the data’s value and deliver it out to mobile tiers perhaps. Does that follow in your thinking that the data is actually more prominent as a resource perhaps on par with applications?

Walker: You’re spot on, Dana. Before the commoditization of these technologies that resided on premises, we could get away with starting at the application layer and work our way back because we had access to the source code or hardware behind our firewalls. We could throw servers out, and we used to put the firewalls in front of the data to solve the problem with infrastructure. So we didn’t have to treat information as a first-class citizen. Times have changed, though.

Information access and processing is now democratized and it’s being pushed as the first point of presentment. A lot of times this is on a mobile device and even then it’s not the corporate’s mobile device, but your personal device. So how do you handle that data?

It’s the same way with Cloud, and I’ll give you a great example of this. I was working as an adviser for a company, and they were looking at their Cloud strategy. They had made a big bet on one of the big infrastructures and Cloud-service providers. They looked first at what the features and functions that that Cloud provider could provide, and not necessarily the information requirements. There were two major issues that they ran into, and that was essentially a showstopper. They had to pull off that infrastructure.

The first one was that in that specific Cloud provider’s terms of service around intellectual property (IP) ownership. Essentially, that company was forced to cut off their IP rights.

Big business

As you know, IP is a big business these days, and so that was a showstopper. It actually broke the core regulatory laws around being able to discover information.

So focusing on the applications to make sure it meets your functional needs is important. However, we should take a step back and look at the information first and make sure that for the people in your organization who can’t say no, their requirements are satisfied.

Gardner: Data architecture is it different from EA and Business Architecture, or is it a subset? What’s the relationship, Dave?

Hornford: Data architecture is part of an EA. I won’t use the word subset, because a subset starts to imply that it is a distinct thing that you can look at on its own. You cannot look at your Business Architecture without understanding your information architecture. When you think about Big Data, cool. We’ve got this pile of data in the corner. Where did it come from? Can we use it? Do we actually have legitimate rights, as Mike highlighted, to use this information? Are we allowed to mix it and who mixes it?

When we look at how our business is optimized, they normally optimize around work product, what the organization is delivering. That’s very easy. You can see who consumes your work product. With information, you often have no idea who consumes your information. So now we have provenance, we have source and as we move for global companies, we have the trends around consumerization, Cloud and simply tightening cycle time.

Gardner: Of course, the end game for a lot of the practitioners here is to create that feedback loop of a lifecycle approach, rapid information injection and rapid analysis that could be applied. So what are some of the ways that these disciplines and tools can help foster that complete lifecycle?

Band: The disciplines and tools can facilitate the right conversations among different stakeholders. One of the things that we’re doing at The Standard is building cadres equally balanced between people in business and IT.

We’re training them in information management, going through a particular curriculum, and having them study for an information management certification that introduces a lot of these different frameworks and standard concepts.

Creating cadres

We want to create these cadres to be able to solve tough and persistent information management problems that affect all companies in financial services, because information is a shared asset. The purpose of the frameworks is to ensure proper stewardship of that asset across disciplines and across organizations within an enterprise.

Hornford: The core is from the two standards that we have, the ArchiMate standard and the TOGAF standard. The TOGAF standard has, from its early roots, focused on the components of EA and how to build a consistent method of understanding of what I’m trying to accomplish, understanding where I am, and where I need to be to reach my goal.

When we bring in the ArchiMate standard, I have a language, a descriptor, a visual descriptor that allows me to cross all of those domains in a consistent description, so that I can do that traceability. When I pull in this lever or I have this regulatory impact, what does it hit me with, or if I have this constraint, what does it hit me with?

If I don’t do this, if I don’t use the framework of the TOGAF standard, or I don’t use the discipline of formal modeling in the ArchiMate standard, we’re going to do it anecdotally. We’re going to trip. We’re going to fall. We’re going to have a non-ending series of surprises, as Mike highlighted.

“Oh, terms of service. I am violating the regulations. Beautiful. Let’s take that to our executive and tell him right as we are about to go live that we have to stop, because we can’t get where we want to go, because we didn’t think about what it took to get there.” And that’s the core of EA in the frameworks.

Walker: To build on what Dave has just talked about and going back to your first question Dana, the value statement on TOGAF from a business perspective. The businesses value of TOGAF is that they get a repeatable and a predictable process for building out our architectures that properly manage risks and reliably produces value.

The TOGAF framework provides a methodology to ask what problems you’re trying to solve and where you are trying to go with your business opportunities or challenges. That leads to Business Architecture, which is really a rationalization in technical or architectural terms the distillation of the corporate strategy.

From there, what you want to understand is information — how does that translate, what information architecture do we need to put in place? You get into all sorts of things around risk management, etc., and then it goes on from there, until what we were talking about earlier about information architecture.

If the TOGAF standard is applied properly you can achieve the same result every time, That is what interests business stakeholders in my opinion. And the ArchiMate modeling language is great because, as we talked about, it provides very rich visualizations so that people cannot only show a picture, but tie information together. Different from other aspects of architecture, information architecture is less about the boxes and more about the lines.

Quality of the individuals

Forde: Building on what Dave was saying earlier and also what Iver was saying is that while the process and the methodology and the tools are of interest, it’s the discipline and the quality of the individuals doing the work

Iver talked about how the conversation is shifting and the practice is improving to build communications groups that have a discipline to operate around. What I am hearing is implied, but actually I know what specifically occurs, is that we end up with assets that are well described and reusable.

And there is a point at which you reach a critical mass that these assets become an accelerator for decision making. So the ability of the enterprise and the decision makers in the enterprise at the right level to respond is improved, because they have a well disciplined foundation beneath them.

A set of assets that are reasonably well-known at the right level of granularity for them to absorb the information and the conversation is being structured so that the technical people and the business people are in the right room together to talk about the problems.

This is actually a fairly sophisticated set of operations that I am discussing and doesn’t happen overnight, but is definitely one of the things that we see occurring with our members in certain cases.

Hornford: I want to build on that what Chris said. It’s actually the word “asset.” While he was talking, I was thinking about how people have talked about information as an asset. Most of us don’t know what information we have, how it’s collected, where it is, but we know we have got a valuable asset.

I’ll use an analogy. I have a factory some place in the world that makes stuff. Is that an asset? If I know that my factory is able to produce a particular set of goods and it’s hooked into my supply chain here, I’ve got an asset. Before that, I just owned a thing.

I was very encouraged listening to what Iver talked about. We’re building cadres. We’re building out this approach and I have seen this. I’m not using that word, but now I’m stealing that word. It’s how people build effective teams, which is not to take a couple of specialists and put them in an ivory tower, but it’s to provide the method and the discipline of how we converse about it, so that we can have a consistent conversation.

When I tie it with some of the tools from the Architecture Forum and the ArchiMate Forum, I’m able to consistently describe it, so that I now have an asset I can identify, consume and produce value from.

Business context

Forde: And this is very different from data modeling. We are not talking about entity relationship, junk at the technical detail, or third normal form and that kind of stuff. We’re talking about a conversation that’s occurring around the business context of what needs to go on supported by the right level of technical detail when you need to go there in order to clarify.

Comments Off

Filed under ArchiMate®, Enterprise Architecture, TOGAF®

Three Best Practices for Successful Implementation of Enterprise Architecture Using the TOGAF® Framework and the ArchiMate® Modeling Language

By Henry Franken, Sven van Dijk and Bas van Gils, BiZZdesign

The discipline of Enterprise Architecture (EA) was developed in the 1980s with a strong focus on the information systems landscape of organizations. Since those days, the scope of the discipline has slowly widened to include more and more aspects of the enterprise as a whole. This holistic perspective takes into account the concerns of a wide variety of stakeholders. Architects, especially at the strategic level, attempt to answer the question: “How should we organize ourselves in order to be successful?”

An architecture framework is a foundational structure or set of structures for developing a broad range of architectures and consists of a process and a modeling component. The TOGAF® framework and the ArchiMate® modeling language – both maintained by The Open Group – are two leading and widely adopted standards in this field.

TA 

While both the TOGAF framework and the ArchiMate modeling language have a broad (enterprise-wide) scope and provide a practical starting point for an effective EA capability, a key factor is the successful embedding of EA standards and tools in the organization. From this perspective, the implementation of EA means that an organization adopts processes for the development and governance of EA artifacts and deliverables. Standards need to be tailored, and tools need to be configured in the right way in order to create the right fit. Or more popularly stated, “For an effective EA, it has to walk the walk, and talk the talk of the organization!”

EA touches on many aspects such as business, IT (and especially the alignment of these two), strategic portfolio management, project management and risk management. EA is by definition about cooperation and therefore it is impossible to operate in isolation. Successful embedding of an EA capability in the organization is typically approached as a change project with clearly defined goals, metrics, stakeholders, appropriate governance and accountability, and with assigned responsibilities in place.

With this in mind, we share three best practices for the successful implementation of Enterprise Architecture:

Think big, start small

The potential footprint of a mature EA capability is as big as the entire organization, but one of the key success factors for being successful with EA is to deliver value early on. Experience from our consultancy practice proves that a “think big, start small” approach has the most potential for success. This means that the process of implementing an EA capability is a process with iterative and incremental steps, based on a long term vision. Each step in the process must add measurable value to the EA practice, and priorities should be based on the needs and the change capacity of the organization.

Combine process and modeling

The TOGAF framework and the ArchiMate modeling language are a powerful combination. Deliverables in the architecture process are more effective when based on an approach that combines formal models with powerful visualization capabilities.

The TOGAF standard describes the architecture process in detail. The Architecture Development Method (ADM) is the core of the TOGAF standard. The ADM is a customer-focused and value-driven process for the sustainable development of a business capability. The ADM specifies deliverables throughout the architecture life-cycle with a focus on the effective communication to a variety of stakeholders. ArchiMate is fully complementary to the content as specified in the TOGAF standard. The ArchiMate standard can be used to describe all aspects of the EA in a coherent way, while tailoring the content for a specific audience. Even more, an architecture repository is a valuable asset that can be reused throughout the enterprise. This greatly benefits communication and cooperation of Enterprise Architects and their stakeholders.

Use a tool!

It is true, “a fool with a tool is still a fool.” In our teaching and consulting practice we have found; however, that adoption of a flexible and easy to use tool can be a strong driver in pushing the EA initiative forward.

EA brings together valuable information that greatly enhances decision making, whether on a strategic or more operational level. This knowledge not only needs to be efficiently managed and maintained, it also needs to be communicated to the right stakeholder at the right time, and even more importantly, in the right format. EA has a diverse audience that has business and technical backgrounds, and each of the stakeholders needs to be addressed in a language that is understood by all. Therefore, essential qualifications for EA tools are: rigidity when it comes to the management and maintenance of knowledge and flexibility when it comes to the analysis (ad-hoc, what-if, etc.), presentation and communication of the information to diverse audiences.

So what you are looking for is a tool with solid repository capabilities, flexible modeling and analysis functionality.

Conclusion

EA brings value to the organization because it answers more accurately the question: “How should we organize ourselves?” Standards for EA help monetize on investments in EA more quickly. The TOGAF framework and the ArchiMate modeling language are popular, widespread, open and complete standards for EA, both from a process and a language perspective. EA becomes even more effective if these standards are used in the right way. The EA capability needs to be carefully embedded in the organization. This is usually a process based on a long term vision and has the most potential for success if approached as “think big, start small.” Enterprise Architects can benefit from tool support, provided that it supports flexible presentation of content, so that it can be tailored for the communication to specific audiences.

More information on this subject can be found on our website: www.bizzdesign.com. Whitepapers are available for download, and our blog section features a number of very interesting posts regarding the subjects covered in this paper.

If you would like to know more or comment on this blog, or please do not hesitate to contact us directly!

Henry Franken

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.

 

 

sven Sven van Dijk Msc. is a consultant and trainer at BiZZdesign North America. He worked as an application consultant on large scale ERP implementations and as a business consultant in projects on information management and IT strategy in various industries such as finance and construction. He gained nearly eight years of experience in applying structured methods and tools for Business Process Management and Enterprise Architecture.

 

basBas van Gils is a consultant, trainer and researcher for BiZZdesign. His primary focus is on strategic use of enterprise architecture. Bas has worked in several countries, across a wide range of organizations in industry, retail, and (semi)governmental settings.  Bas is passionate about his work, has published in various professional and academic journals and writes for several blogs.

2 Comments

Filed under ArchiMate®, Enterprise Architecture, TOGAF®

Successful Enterprise Architecture using the TOGAF® and ArchiMate® Standards

By Henry Franken, BiZZdesign

The discipline of Enterprise Architecture was developed in the 1980s with a strong focus on the information systems landscape of organizations. Since those days, the scope of the discipline has slowly widened to include more and more aspects of the enterprise as a whole. This holistic perspective takes into account the concerns of a wide variety of stakeholders. Architects, especially at the strategic level, attempt to answer the question “How should we organize ourselves in order to be successful?”

An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures and consists of a process and a modeling component. TOGAF® framework and the ArchiMate® modeling language – both maintained by The Open Group® – are the two leading standards in this field.

TA

Much has been written on this topic in online forums, whitepapers, and blogs. On the BiZZdesign blog we have published several series on EA in general and these standards in particular, with a strong focus on the question: what should we do to be successful with EA using TOGAF framework and the ArchiMate modeling language? I would like to summarize some of our findings here:

Tip 1 One of the key success factors for being successful with EA is to deliver value early on. We have found that organizations who understand that a long-term vision and incremental delivery (“think big, act small”) have a larger chance of developing an effective EA capability
 
Tip 2 Combine process and modeling: TOGAF framework and the ArchiMate modeling language are a powerful combination. Deliverables in the architecture process are more effective when based on an approach that combines formal models with powerful visualization capabilities. Even more, an architecture repository is an valuable asset that can be reused throughout the enterprise
 
Tip 3 Use a tool! It is true that “a fool with a tool is still a fool”. In our teaching and consulting practice we have found, however, that adoption of a flexible and easy to use tool can be a strong driver in pushing the EA-initiative forward.

There will be several interesting presentations on this subject at the upcoming Open Group conference (Newport Beach, CA, USA, January 28 – 31: Look here), ranging from theory to case practice, focusing on getting started with EA as well as on advanced topics.

I will also present on this subject and will elaborate on the combined use of The Open Group standards for EA. I also gladly invite you to join me at the panel sessions. Look forward to see you there!

Henry FrankenHenry 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.

2 Comments

Filed under ArchiMate®, Enterprise Architecture, 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®

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

By Thomas Obitz, KPMG

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

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

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

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

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

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

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

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

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


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

1 Comment

Filed under Business Architecture, TOGAF®

ArchiMate 2.0 – Ready for the Future of Enterprise Architecture!

By Henry Franken, BIZZdesign

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

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

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

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

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

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

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

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

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

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

4 Comments

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

Video Highlights Day 2 of Washington, D.C.

By The Open Group Conference Team

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

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

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

Comments Off

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

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

By Jim Hietala, The Open Group

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comments Off

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

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

By Andrew Josey, The Open Group

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

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

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

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

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

(This blog post was edited on August 16)

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

14 Comments

Filed under Certifications, Enterprise Architecture, TOGAF®

Leveraging TOGAF to Deliver DoDAF Capabilities

By Chris Armstrong, Armstrong Process Group

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

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

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

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

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

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

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

Hope to see you there!

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

 

2 Comments

Filed under Conference, Enterprise Architecture, TOGAF®

Adapting to an eBook World

By Chris Harding, The Open Group

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

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

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

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

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

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

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

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

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

Comments Off

Filed under Cloud/SOA, TOGAF®

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

By Dana Gardner, Interarbor Solutions

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

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

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

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

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

Here are some excerpts:

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

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

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

One-stop shop

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

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

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

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

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

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

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

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

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

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

Two-way street

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

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

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

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

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

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

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

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

Different perspectives

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

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

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

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

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

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

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

Providing guidance

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

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

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

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

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

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

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

Internalize best practices

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

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

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

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

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

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

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

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

Driving the realization

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

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

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

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

Comments Off

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

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

By Isabela Abreu, The Open Group

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

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

Introduction to Brazil

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

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

Enterprise Architecture

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

Security

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

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

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

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

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

1 Comment

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