Tag Archives: architecture

TOGAF® User Group Meeting Preview: A Conversation with Terry Blevins

By The Open Group

The Open Group will be hosting its first TOGAF® User Group Meeting on January 25 in San Francisco. We recently spoke with long-time member, Terry Blevins, The Open Group Board Member, Fellow and former Chair of The Open Group Architecture Forum about his involvement over the years with TOGAF®, an Open Group standard.  We also discussed what users can look forward to at the User Group Meeting.

What’s your history with TOGAF? How long have you been a TOGAF user?

I’ve been involved with The Open Group since before it was The Open Group, when it was X/Open. I first engaged with The Open Group in the architecture area when they were working on the first or second release of TOGAF—that was around 1996. For a number of releases of TOGAF, I was a direct contributor. I was also a Co-chair of the Architecture Forum and chaired the Work Group covering certification of TOGAF architects for a couple years.

One of the main contributions I made to TOGAF was the Business Scenario Method, which is what I’ll be talking about in one of the breakout sessions at the User Group Meeting. For the past number of years, I’ve been on The Open Group Governing Board, so I haven’t participated directly in the Architecture Forum or its Work Groups, but I do keep my eye on things. Most recently I’ve been involved in the Healthcare Forum, with an eye on applying the disciple of architecture to improve healthcare information flow.

When you were a TOGAF contributor, what types of things were you contributing to the standard?

When I first contributed content ,I was working for NCR Corporation where we were keen on seeing standard approaches to architecture. The whole thing is that you bring contributions to the standard from your company or from your personal experience that are practical and that work. The Business Scenario Method was something that I created to help companies understand real, live business needs, and this is essential for any architecting project. Other contributions were spread throughout the early versions of the TOGAF specification.

Why a User Group Meeting now?

The growth of the number of people who are certified in TOGAF is huge. It’s truly become an accepted method worldwide and has resulted in pull from the business side of organizations. That pull and worldwide interest generates a need for people to come together and share. In addition, I think there is a greater occurrence of procurements for architects that are certified in TOGAF today. So that puts the importance in the user community on truly understanding how to apply TOGAF, which drives a need for a place where users can go. Another dimension is, of course, in reaching out to the user community to drive TOGAF with requirements that represent the users!

Those certified and/or using TOGAF have always had the Architecture Forum as a venue where they could share, but the Architecture Forum has become so big and so concentrated on the aspects of developing the method. Many in the TOGAF user community are not interested in developing methods; their interest is in the application of the method. They really want to have a forum to go to where they can talk to other users of TOGAF and talk about what works, what doesn’t work, share their stories and accomplishments and get some hints on how to avoid failures. It’s more about the application of TOGAF.

We’d always thought that there would be a point in time where it would be very difficult for the Architecture Forum to serve both the purpose of users and of people that were methodologists. We may have hit that point. Having a forum that is less formal, like a user group, is attractive to users. Then they can also gather requirements and send them off to the Architecture Forum and say ‘this is our collective voice on constructive improvement points for TOGAF. Do with them what you may.’

What can users expect from the User Group Meeting?

I tell people that we want the users to ‘SEE’ TOGAF differently, differently in comparison to reading the book, getting the training or taking tests. What I mean by ‘SEE’ is that we want users to be able to ‘share’ experiences, so that’s the ‘s’ part of ‘see.’ We want the users to get ‘enlightened’ on new things down the road and the current thinking on what might be next. And we also want users to feel that they’re ‘engaged’ in making improvements to TOGAF. We want to provide the users the ability to share their experiences, successes and failures, get information that they might not get in the books or the training and have the opportunity to say ‘Hey, this should change.’ So that’s SEE—Share, Enlightenment and Engagement.

You’re hosting the Using the Business Scenarios track – what can users look forward to in that track?

In the Business Scenario session, I wanted to make sure that we have some structure and an agenda. But if the structure breaks down because the users want to take the conversation someplace, we’ll let that happen. The structure was created to cover sharing, engagement and enlightenment—the users can change that if they want. If the structure holds, I’ll provide some background on what the Business Scenario method is, and we’ll ask for some stories about how the users get customer requirements, what challenges they have, special techniques they use and key successes and barriers. Then we’ll look at what needs to be done to make the Business Scenario Method better or what we can do to make capturing requirements easier and open up that conversation. Finally, we’ll talk about the latest thinking regarding Business Scenarios. There’s some changes I’ve recently made to the method, and I’ve also added some tips, tricks and techniques that I’ll share with the users. The focus will be on how people really get the business requirements they need to drive their architecting work.

What do you consider to be the primary benefits having a user meeting for TOGAF?

I hope the benefit is that they’re really learning from other users and learn what pitfalls to avoid. Their benefit is they’re getting the experience of other users, and that’s going to make them better architects. Secondly, they have a real opportunity to provide their voice on what needs to be done to make the tools better so they can have something in the future that will be better positioned to make them better architects. With active participation, the attendees are going to learn some things that will help them be better architects, which is going to make them more desirable and hopefully they’ll have better career opportunities.

What else do you hope users will get out of the User Group Meeting?

The pride in being able to say they are part of the larger community and an active participant in putting together a voice capable of moving the discipline of architecture forward.

How will the User Group Meeting help inform the evolution of the standard?

By gathering requirements. We’ve designed some TOGAF improvement suggestion index cards that we’ll pass out to users and ask them to fill out the cards whenever they come up with an idea for an improvement. We’ll ask them to turn those in, and, by the way, for each card they’ll get a raffle ticket, which will be fed into a downstream process to improve TOGAF. That engagement part of the event is being facilitated through these cards. We’ll collect the cards, do an analysis and then make recommendations to the Architecture Forum.

It’s the first go, so we hope it will inspire more events, more mechanisms to collect TOGAF requirements and greater sharing experiences. We also hope the user community will take an active role in shaping how these user group sessions may evolve.

For more information on The Open Group San Francisco 2016, please visit http://www.opengroup.org/sanfrancisco2016.

@theopengroup #ogSFO

 

Leave a comment

Filed under architecture, The Open Group, The Open Group San Francisco 2016, TOGAF®, Uncategorized

The 20th Anniversary of the UNIX® Standard and Certification

By The Open Group

The UNIX® platform, as a technology, has been around more than 40 years, being at the center of innovation and technology in computer science and driving the Fortune 1000 businesses today. Over twenty years ago, a number of companies came together to acknowledge the value of the UNIX platform, but more importantly, the need for all UNIX implementations to be interoperable and compatible to support the tremendous ecosystem built on top of UNIX systems. An open and inclusive collaboration followed, which led to the creation of the Single UNIX Specification, the industry standard for UNIX systems. The standard is supported by extensive certification tests to ensure that the theory of interoperability and compatibility became a reality with suppliers, vendors and customers knowing and demanding UNIX certification in their solution. UNIX, the go-to operating system, is trusted for mission critical applications because it is robust with a powerful footprint and is inherently more secure and stable than the alternatives. The first UNIX certifications were awarded twenty years ago this year.

During the following 20 years, the UNIX standard has continued to evolve and embrace new technology. The most recent version UNIX V7 is the latest step in the evolution of the standard, but by no means the end as there is greater and greater demand by those developing UNIX operating systems, those who integrate UNIX operating system in their solutions and, most importantly, the customers who deploy those solutions as part of their business innovation.

“The UNIX platform demonstrates the value of being open, since as a truly open standard it allows all to focus on driving innovation of the ecosystem around the platform rather than competing at the core OS level.  The open standard makes it easier for software developers’ portability, integrators to have choice in the building blocks of solutions and customers focus on solving business problems than integration issues,” says Steve Nunn, CEO, The Open Group.

“The Open Group from day one has been the shepherd for the standard leveraging its long history in the development of open standards. This ensures the value of the standard UNIX platform grows for both member companies who contribute, as well as those who demand openness as part of their solution,” comments Andrew Josey, Director, Standards, The Open Group.

Please join The Open Group and our Platinum Member UNIX Partners in celebrating this momentous 20-year milestone.

@theopengroup @unixr

 

 

4 Comments

Filed under interoperability, Single UNIX Specification, standards, Uncategorized, UNIX

The Open Group Edinburgh 2015: BAE Systems – Using TOGAF® for Operations Transformation

By The Open Group

When Matthew Heard first heard the term TOGAF®, not only did he have no idea what it was but he misspelled the name of the standard at first. It wasn’t until after searching Google for “TOGATH” that the real name for the architectural framework popped up and he got a sense for what it was, he says. And thus began a more than 15-month journey that has started Heard and his colleagues at BAE Systems, a British defense, aerospace and security systems provider, down a path to help transform the Operations function of the company’s Maritime Submarine division.

As is the case when any company looks to TOGAF, an Open Group standard, BAE’s Submarine division was in search of a structured way to help make organizational changes when they sought out the framework. According to Heard, a Senior Operations Engineer at BAE, the company’s needs were multifold. As a product manufacturer, BAE was in need of a way to prepare their systems to transition from their current product to the next generation. With a new product planned to go into production in the near future—one that would require higher technical demands and performance—the company first needed to set itself up to smoothly move into production for the higher demand product while still building the current product line.

In addition, the company wanted to make operational changes. After having surveyed 3,000 of their employees regarding what could be done to make people’s jobs easier and make the company a better place to work, the company had received 8,000 comments about how to create a better working environment. After winnowing those down to 800 separate problem statements that included ideas on how to improve things like safety, deliverables and the overall workplace, the team had many potential ideas and solutions, but no way to determine where to start.

“How do you structure things so that you don’t try to do everything at once and therefore don’t do anything because it’s too overwhelming?” Heard says. “We had a lot of change to make but we couldn’t quantify what it was and what order to do it in.”

As it happened, IBM’s Paul Homan had been doing some work on-site with BAE. When he heard that the company was looking to make some organizational changes, he suggested they look at an Enterprise Architecture framework, such as TOGAF. Although the company’s new head of transformation was familiar with the framework, there were no Enterprise Architects on staff, no TOGAF certified employees and no one else on staff had heard of the standard or of Enterprise Architecture, Heard says. Thus the mix-up the first time he tried to look it up online.

After downloading a copy of TOGAF® 9.1, Heard and his colleague John Wilcock began the task of going through the entire standard to determine if it would help them.

And then they did something very unusual.

“The first thing we did was, anything with more than three syllables, we crossed out with a black pen,” Heard says.

Why did they go through the text and black out entire sections as if it were a classified document riddled with redacted text?

According to Heard, since many of the terms used throughout the TOGAF standard are technology and IT-driven, they knew that they would need to “translate” the document to try to adapt it to their industry and make it understandable for their own internal audiences.

“It talked about ‘Enterprise Architecture,’” Heard said. “If we said that to a welder or pipe fitter, no one’s going to know what that means. I didn’t even know what it meant.”

As a recent university graduate with a background in Engineering Management, Heard says the IT terminology of TOGAF was completely foreign to him. But once they began taking out the IT-related language and began replacing it with terminology related to what submarine mechanics and people in operations would understand, they thought they might be able to better articulate the framework to others.

“We didn’t know whether we had gone so far away from the original intent or whether we were still on the right line,” Heard says.

Luckily, with Paul Homan on-site, they had someone who was familiar with TOGAF that they could go to for guidance. Homan encouraged them to continue on their path.

“For example, it might say something like ‘define the enterprise architecture vision,’” Heard says. “Well I just crossed out the word ‘architecture’ and turned the word ‘enterprise’ into ‘function’ so it said ‘define the functional vision.’ Well, I can do that. I can define what we want the function to look like and operate like and have the performance that we need. That becomes tangible. That’s when we went back to Paul and asked if we were on the right track or if we were just making it up. He said, ‘Carry on with what you’re doing.’”

As it turned out, after Heard and Wilcock had gone through the entire 900-page document, they had maintained the essence and principles of TOGAF while adapting it so that they could use the framework in the way that made the most sense to them and for BAE’s business needs. They adapted the methodology to what they needed it to do for them—which is exactly what the TOGAF ADM is meant to do anyway.

TOGAF was ultimately used to help define BAE’s strategy for transforming their operations and production functions. The project is currently at the stage where they are moving from defining a scope of projects to planning which projects to begin with. The team has scoped approximately 27 transformation projects that will take place over approximately three to five years.

Heard says that it was a fortuitous coincidence that Homan was there to suggest the framework since it ultimately provided exactly the guidance they needed. But Heard also believes that it was also fortuitous that no one was familiar with the standard beforehand and that they took the risk of translating it and adapting it for their own needs. He feels had they already been trained in TOGAF before they started their project, they would have spent more time trying to shoehorn the standard into what they needed instead of just adapting it from the start.

“That was the real learning there,” he says.

Now Heard says he finds himself using the framework on a daily basis for any project he has to tackle.

“It’s now become a routine go-to thing even if it’s a very small project or a piece of work. It’s very easy to understand how to get to an answer,” he says.

Heard says that by providing a structured, standardized approach to solving problems, TOGAF ultimately allows organizations to not only take a structured approach to transformational projects, but also to document and measure their success along the way, which is key for meeting business objectives.

“Standardization gives process to projects. If you follow the same approach you become more efficient. If there’s no standard, you can’t do that.”

Learn more about how BAE is using TOGAF® for Business Transformation at The Open Group Edinburgh, October 19-22, 2015

Join the conversation #ogEDI

By The Open GroupMatthew Heard attended the University of Birmingham from where he graduated with an MSc in Engineering Management in 2013. During his time at University Matthew worked as a Project Engineer for General Motors, focusing on the development of improvements in efficiency of the production line. Upon graduating Matthew joined BAE Systems-Maritime-Submarines looking for a new challenge and further experience of change and improvement programmes. Since Matthew joined BAE his predominant focus has been the delivery of Operational change initiatives. Matthew undertook a review and translation of the TOGAF principles and objectives to develop a unique strategy to deliver a program of change for the Operations Function, the outputs of which delivered the Operations Transformation Strategic Intent and Work Scopes. Going forward Matthew aims to continue developing and utilising the principles and objectives of TOGAF to aid other functions within BAE with their own future strategic developments, starting with the HR Transformation Work Scope.

By The Open GroupJohn Wilcock has worked within the Maritime Sector for the last 27 years. Starting as a shipwright apprentice, John has worked his way up through the organisation to his current position as Head of Manufacturing & Construction Strategy. Throughout his career John has gained a wide range of experiences, working on a diverse selection of Defence and Commercial projects, including Warship and Submarine platforms. During this time John has been instrumental in many change programmes and in his current role John is responsible for the development and delivery of the functional Transformation and Build Strategies. In order to develop the Operations Transformation Strategy John has worked alongside Matthew Heard to undertake a review and translation of the TOGAF principles and objectives to create a bespoke strategic intent and work scope. John continues to drive change and transformation through the TOGAF principles.

By The Open GroupPaul Homan

Enterprise Architect at IBM, CTO for Aerospace, Defence & Shipbuilding IBM UKI

Comments Off on The Open Group Edinburgh 2015: BAE Systems – Using TOGAF® for Operations Transformation

Filed under architecture, Enterprise Transformation, Standards, TOGAF, TOGAF®

In Praise Of Heuristics – or Saving TOGAF® From Its Friends

By Stuart Boardman, Senior Business Consultant, Business & IT Advisory, KPN Consulting and Ed Harrington, Senior Consulting Associate, Conexiam

As the world’s best known and most used Enterprise Architecture (EA) framework, it’s quite reasonable that TOGAF®, an Open Group standard, attracts criticism from both outside and within The Open Group membership. We would like to discuss a particular class of criticism and even more about the thinking behind that.

This criticism states that TOGAF is neither rigorous nor scientific and that any good EA framework should be both of those things. Now we don’t know anyone who wouldn’t agree that TOGAF could be more rigorous about some things and that’s one of the areas highlighted for attention in the next version of TOGAF.

But, “scientific”? There’s the rub. What do we mean by scientific?

Machines, Nature and Enterprises

What these critics promote is a method, which for any given enterprise, under identical conditions will always deliver the same, “correct” result – regardless who executes the method, as long as they follow the rules. This approach depends on a very 19th/20th Century mechanistic view of an enterprise.

We agree that an enterprise is a system. Mechanical systems behavior is generally predictable. If you get the equation right, you can predict the behavior under any given set of conditions with an accuracy of (to all intents and purposes) 100%. So, if an enterprise were a machine, you could come up with a method that meets this requirement.

Natural and environmental systems do not, in general, behave predictably (leaving trivia like Pavlov and his dogs out of it). There is room for discussion for any one system under consideration as to why this is. It could just be because there are so many variables that we can’t capture all of them at one instant in time (i.e. they are highly complex) or because the system is chaotic (i.e. extremely sensitive to initial conditions) or even stochastic (i.e. we can only establish a probability for a particular outcome) – or possibly a mixture of those things.

A major aspect of enterprises is that, to a considerable extent, they are made up of people, individually and in groups. Each with their shifting perceptions of what “good” is. In fact even a single organization behaves more like an organism than like a machine (note: we are not claiming that organizations are organisms).

Especially important is that enterprises function within wider ecosystems in which external factors like resource availability, innovation, competition, customer loyalty, legislation and regulation (to name but a few) constantly affect the behavior of the enterprise. To reliably predict the behavior of the enterprise we would need to know each and every factor that affects that behavior. Complexity is a major factor. Do we recognize any existing enterprises that do not conform to this (complex) model?

Science and Uncertainty

Enterprises are complex and, we would argue, even chaotic systems. Change the initial conditions and the behavior may be radically different (a totally different equation). A real scientific method for EA would then necessarily reflect that. It would deliver results, which could continue to adapt along with the enterprise. That requires more than just following a set of rules. There is no “equation”. There may be a number of “equations” to choose from. Some degree of experience, domain knowledge and empathy is required to select the most adaptable of those equations. If the world of software architecture hasn’t yet determined a formula for the perfect agile system, how can we imagine the even more complex EA domain could?[1] Any such method would be a meta-method. The actual method followed would be an adaptation (concretization/instantiation) of the meta-method for the system (i.e. enterprise) under examination in its then specific context.

So even if there is an EA method that delivers identical results independent of the user, the chances they’d be correct are…well, just that – chance. (You probably have a better chance of winning the lottery!). The danger of these “scientific” approaches is that we kid ourselves that the result must be right, because the method said so. If the objective were only to produce a moment in time “as-is” view of an enterprise and if you could produce that before everything changed again, then a mechanistic approach might work. But what would be the point?

What Really Bothers Us

Now if the problem here were restricted to the proponents of this “scientific” view, it wouldn’t matter too much, as they’re not especially influential, especially on a global scale. Our concern is that it appears TOGAF is treated by a considerably larger number of people as being exactly that kind of system. Some of the things we read by TOGAF-certified folk on, for example, LinkedIn or come across in practice are deeply disturbing. It seems that people think that the ADM is a recipe for making sausages and that mechanistically stepping through the crop circles will deliver a nicely formed sausage.

Why is this? No TOGAF expert we know thinks TOGAF is a linear, deterministic process. The thousands of TOGAF certified people have a tool that, as TOGAF, itself in chapter 2.10 states: “In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise”.

Is it perhaps an example of the need so many people have to think the whole world is predictable and controllable – an unholy fear of uncertainty? Such people seek comfort and the illusion of certainty in a set of rules. That would certainly fit with an outdated view of science. Or perhaps the problem is located less with the architects themselves than with management by spreadsheet and with project management methodologies that are more concerned with deadlines than with quality? Less experienced architects may feel obliged to go along with this and thus draw the wrong conclusions about TOGAF.

The Task of Enterprise Architecture

Understanding, accepting and taking advantage of the presence of uncertainty is essential for any organization today. This would be true even if it were only because of the accelerating rate of change. But more than that, we need to recognize that the way we do business is changing, that agile organizations encourage emergence[2] and that success means letting go of hard and fast rules. Enterprise architects, to be useful, have to work with this new model, not to be risk averse and to learn from (shared) experience. It’s our responsibility to help our enterprises achieve their strategic goals. If we turn our backs on reality, we may be able to tick off a task on a project plan but we’re not helping anyone.

A good EA framework helps us understand what we need to do and why we are doing it. It doesn’t do the thinking for us. All good EA frameworks are essentially heuristics. They assemble good practice from the experience of real practitioners and provide guidance to assist the intelligent architect in finding the best available solution – in the knowledge that it’s not perfect, that things can and will change and that the most valuable strategy is being able to cope with that change. TOGAF helps us do this.

[1] For more on complexity and uncertainty see Tom Graves’s SCAN method.

[2] See, for example Ruth Malan and Dana Bredemeyer’s The Art of Change: Fractal and Emergent

By Stuart Boardman, KPN, and Ed Harrington, ConexiumStuart Boardman is a Senior Business Consultant with KPN Consulting where he leads the Enterprise Architecture practice and consults to clients on Cloud Computing, Enterprise Mobility and The Internet of Everything. He is Co-Chair of The Open Group Open Platform 3.0™ Forum and was Co-Chair of the Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by KPN, the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI as well as several Open Group white papers, guides and standards. He is a frequent speaker at conferences on the topics of Open Platform 3.0 and Identity.

Ed Harrington is a Senior Consulting Associate with Conexiam, a Calgary, Canada headquartered consultancy. He also heads his own consultancy, EPH Associates. Prior positions include Principle Consultant with Architecting the Enterprise where he provided TOGAF and other Enterprise Architecture (EA) discipline training and consultancy; EVP and COO for Model Driven Solutions, an EA, SOA and Model Driven Architecture Consulting and Software Development company; various positions for two UK based companies, Nexor and ICL and 18 years at General Electric in various marketing and financial management positions. Ed has been an active member of The Open Group since 2000 when the EMA became part of The Open Group and is past chair of various Open Group Forums (including past Vice Chair of the Architecture Forum). Ed is TOGAF® 9 certified.

4 Comments

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

The Open Group Madrid Summit 2015 – An Interview with Steve Nunn

By The Open Group

The Open Group will be hosting its Spring 2015 summit in Madrid from April 20-23. Focused on Enabling Boundaryless Information Flow™, the summit will explore the increasing digitalization of business today and how Enterprise Architecture will be a critical factor in helping organizations to adapt to the changes that digitalization and rapidly evolving technologies are bringing.

In advance of the summit, we spoke to Steve Nunn, Vice President and COO of The Open Group and CEO of the Association of Enterprise Architects (AEA) about two speaking tracks he will be participating in at the event—a panel on the challenges facing young Enterprise Architects today, and a session addressing the need for Enterprise Architects to consider their personal brand when it comes to their career path.

Tell us about the panel you’ll be moderating at the Madrid Summit on EA Challenges.

The idea for the panel really came from the last meeting we had in San Diego. We had a panel of experienced Enterprise Architects, including John Zachman, giving their perspectives on the state of Enterprise Architecture and answering questions from the audience. It gave us the idea that, we’ve heard from the experienced architects, what if we also heard from younger folks in the industry, maybe those newer to the profession than the previous panel? We decided to put together a panel of young architects, ideally local to Madrid, to get what we hope will be a different set of perspectives on what they have to deal with on a day-to-day basis and what they see as the challenges for the profession, what’s working well and what’s working less well. In conjunction with the local Madrid chapter of the AEA, we put the panel together. I believe it’s a panel of four young architects, plus a gentleman named Juan Abel, who is the chair of the local chapter in Madrid, who helped put it together, with me moderating. The Madrid chapter of the AEA has been very helpful in putting together the summit in Madrid and with details on the ground, and we thank them for all their help.

We’ll be putting some questions together ahead of time, and there will be questions from the audience. We hope it will be a different set of perspectives from folks entering the profession and in a different geography as well, so there may be some things that are particular to practicing Enterprise Architecture in Spain which come out as well. It’s a long panel—over an hour—so, hopefully, we’ll be able to not just hit things at a cursory level, but get into more detail.

What are some of the challenges that younger Enterprise Architects are facing these days?

We’re hoping to learn what the challenges are for those individuals, and we’re also hoping to hear what they think is attracting people to the profession. That’s a part that I’m particularly interested in. In terms of what I think going in to the panel session, the thing I hear about the most from young architects in the profession is about the career path. What is the career path for Enterprise Architects? How do I get in? How do I justify the practice of Enterprise Architecture in my organization if it doesn’t exist already? And if it does exist, how do I get to be part of it?

In the case of those individuals coming out of university—what are the relevant qualifications and certifications that they might be looking at to give themselves the best shot at a career in Enterprise Architecture. I expect it will be a lot of discussion about getting into Enterprise Architecture and how do you best position yourself and equip yourself to be an Enterprise Architect.

Were there things that came out of the San Diego session that will be relevant to the Madrid panel?

There were certainly some things discussed about frameworks and the use of frameworks in Enterprise Architecture. Being an Open Group event, obviously a lot of it was around TOGAF®, an Open Group standard, and with John Zachman as part of it, naturally the Zachman Framework too. There was some discussion about looking into how the two can play more naturally together. There was less discussion about the career development aspect, by and large because, when these people started out in their careers, they weren’t Enterprise Architects because it wasn’t called that. They got into it along the way, rather than starting out with a goal to be an Enterprise Architect, so there wasn’t as much about the career aspect, but I do think that will be a big part of what will come out in Madrid.

I think where there are overlaps is the area around the value proposition for Enterprise Architecture inside an organization. That’s something that experienced architects and less experienced architects will face on a day-to-day basis in an organization that hasn’t yet bought into an Enterprise Architecture approach. The common theme is, how do you justify taking Enterprise Architecture inside an organization in a way that delivers value quick enough for people to see that something is happening? So that it’s not just a multi-year project that will eventually produce something that’s nicely tied up in a bow that may or may not do what they wanted because, chances are, the business need has moved on in that time anyway. It’s being able to show that Enterprise Architecture can deliver things in the short term as well as the long term. I think that’s something that’s common to architects at all stages of their careers.

You’re also doing a session on creating a personal brand in Madrid. Why is branding important for Enterprise Architects these days?

I have to say, it’s a lot of fun doing that presentation. It really is. Why is it important? I think at a time, not just for Enterprise Architects but for any of us, when our identities are out there so much now in social media—whatever it may be, Facebook, LinkedIn, other social media profiles— people get a perception of you, many times never having met you. It is important to control that perception. If you don’t do it, someone else may get a perception that you may or may not want from it. It’s really the idea of taking charge of your own brand and image and how you are perceived, what values you have, what you want to be known for, the type of organization you want to work in, the types of projects that you want to be involved in. Not all of those things happen at once, they don’t all land on a plate, but by taking more control of it in a planned way, there’s more chance of you realizing some of those goals than if you don’t. That’s really the essence of it.

The timing and particular relevance to Enterprise Architects is that, more and more, as organizations do see value in Enterprise Architecture, Enterprise Architects are getting a seat at the top table. They’re being listened to by senior management, and are sometimes playing an active role in strategy and important decisions being made in organizations. So, now more than ever, how Enterprise Architects are being perceived is important. They need to be seen to be the people that can bring together the business people and IT, who have the soft skills, being able to talk to and understand enough about different aspects of the business to get their job done. They don’t have to be experts in everything, of course, but they have to have a good enough understanding to have meaningful discussions with the people with whom they’re working. That’s why it’s crucial at this time that those who are Enterprise Architects, as we build the profession, are perceived in a positive way, and the value of that is highlighted and consistently delivered.

A lot of technologists don’t always feel comfortable with overtly marketing themselves—how do you help them get over the perception that having a personal brand is just “marketing speak?”

That’s something that we go through in the presentation. There are 11 steps that we recommend following. This goes back to an old Tom Peters article that was written years ago titled ‘The Brand Called You’ . Many of us aren’t comfortable doing this and it’s hard, but it is important to force yourself to go through this so your name and your work and what you stand for are what you want them to be.

Some of the suggestions are to think of the things that you’re good at and what your strengths are, and to test those out with people that you know and trust. You can have some fun with it along the way. Think about what those strengths are, and think about what it is that you offer that differentiates you.

A big part of the personal brand concept is to help individuals differentiate themselves from everyone else in the workplace, and that’s a message that seems to resonate very well. How do you stand out from lots of other people that claim to have the same skills and similar experience to yourself? Think of what those strengths are, pick a few things that you want to be known for. Maybe it’s that you never miss a deadline, you’re great at summarizing meetings or you’re a great facilitator—I’m not suggesting you focus on one—but what combination of things do you want to be known for? Once you know what that is—one of the examples I use is, if you want to be known for being punctual, which is an important thing, make sure you are—set the alarm earlier, make sure you show up for meetings on time, then that’s one of the things you’re known for. All these things help build the personal brand, and when people think of you, they think of how they can rely on you, and think of the attributes and experience that they can get from working with you.

That’s really what it comes down to—as human beings, we all prefer to work with people we can trust. Ideally people that we like, but certainly people that we can trust and rely on. You’re far more likely to get the right doors opening for you and more widely if you’ve built a brand that you maintain, and people you work with know what you stand for and know they can rely on you. It’s going to work in your favor and help you get the opportunities that you hope for in your career.

But there’s a big fun aspect to the presentation, as well. I start the presentation looking at branding and the types of brands that people know what they stand for. I think it has scope for workshop-type sessions, as well, where people follow some of the steps and start developing their personal brands. Feedback on this presentation has been very positive because it stands out as a non-technical presentation, and people can see that they can use it privately to further their careers, or to use it with their teams within their organizations. People really seem to resonate with it.

As CEO of the Association of Enterprise Architects, what are you seeing in terms of career opportunities available for architects right now?

We are seeing a lot of demand for Enterprise Architects all over the place, not just in the U.S., but globally. One of the things we have on the AEA website is a job board and career center, and we’ve been trying to increase the number of jobs posted there and make it a useful place for our members to go when they’re considering another position, and a good place for recruiters to promote their openings. We are growing that and it’s being populated more and more. Generally, I hear that there is a lot of demand for Enterprise Architects, and the demand outweighs the supply at the moment. It’s a good time to get into the profession. It’s a good time to be making the most of the demand that’s out there in the market right now. To back that up, the latest Foote Report showed that the OpenCA and TOGAF certifications were among the most valuable certifications in the IT industry. I think there is demand for certified architects and what we’re doing in the AEA is building the professional body to the point, ultimately, where people not only want to be AEA members, but effectively need to be AEA members in order to be taken seriously in Enterprise Architecture.

We’re also seeing an increasing number of inquiries from organizations that are recruiting Enterprise Architects to check that the applicant is indeed an AEA member. So clearly that tells us that people are putting it down on their resumes as something that differentiates them. It’s good that we get these inquiries, because it shows that there is perceived value in membership.

What’s new with the AEA? What’s happening within the organization right now?

Other things we have going on are a couple of webinar series running in parallel. One is a series of 13 webinars led by Jason Uppal of QRS Systems. He’s giving one a month for 13 months—we’ve done seven or eight already. The other is a series of 10 webinars given by Chris Armstrong of the Armstrong Process Group. What they have in common is that they are tutorials, they’re educational webinars and learning opportunities, and we’re seeing the number of attendees for those increasing. It’s a value of being an AEA member to be able to participate in these webinars. Our focus is on giving more value to the members, and those are a couple of examples of how we’re doing that.

The other thing that we have introduced is a series of blogs on ‘What Enterprise Architects Need to Know About…’ We’ve covered a couple of topics like Internet of Things and Big Data—we have more planned in that series. That’s an attempt to get people thinking about the changing environment in which we’re all operating now and the technologies coming down the pike at us, and what it means for Enterprise Architects. It’s not that architects have to be an expert in everything, but they do need to know about them because they will eventually change how organizations put together their architectures.

By The Open GroupSteve Nunn is the VP and Chief Operating Officer of The Open Group. Steve’s primary responsibility for The Open Group is to ensure the legal protection of its assets, particularly its intellectual property. This involves the development, maintenance and policing of the trademark portfolio of The Open Group, including the registered trade marks behind the Open Brand and, therefore, the various Open Group certification programs, including TOGAF®, Open CA, Open CITS, and UNIX® system certification. The licensing, protection and promotion of TOGAF also falls within his remit.

In addition, Steve is CEO of the Association of Enterprise Architects (AEA) and is focused on creating and developing the definitive professional association for enterprise architects around the globe. To achieve this, Steve is dedicated to advancing professional excellence amongst AEA’s 20,000+ members, whilst raising the status of the profession as a whole.

Steve is a lawyer by training and has an L.L.B. (Hons) in Law with French and retains a current legal practising certificate.

Join the conversation @theopengroup #ogchat #ogMAD

 

 

Comments Off on The Open Group Madrid Summit 2015 – An Interview with Steve Nunn

Filed under Boundaryless Information Flow™, Brand Marketing, Enterprise Architecture, Internet of Things, Open CA, Standards, TOGAF, TOGAF®, Uncategorized

The Open Group San Diego Panel Explores Synergy Among Major Frameworks in Enterprise Architecture

Following is a transcript of part of the proceedings from The Open Group San Diego event in February – a panel discussion on The Synergy of Enterprise Architecture frameworks.

The following panel, which examines the synergy among the major Enterprise Architecture frameworks, consists of moderator Allen Brown, President and Chief Executive Officer, The Open Group; Iver Bank, an Enterprise Architect at Cambia Health Solutions; Dr. Beryl Bellman, Academic Director, FEAC Institute; John Zachman, Chairman and CEO of Zachman International, and originator of the Zachman Framework; and Chris Forde, General Manager, Asia and Pacific Region and Vice President, Enterprise Architecture, The Open Group.

Here are some excerpts:

By The Open GroupIver Band: As an Enterprise Architect at Cambia Health Solutions, I have been working with the ArchiMate® Language for over four years now, both working with and on it in the ArchiMate® Forum. As soon as I discovered it in late 2010, I could immediately see, as an Enterprise Architect, how it filled an important gap.

It’s very interesting to see the perspective of John Zachman. I will briefly present how the ArchiMate Language allows you to fully support enterprise architecture using The Zachman Framework. So I am going to very briefly talk about enterprise architecture with the ArchiMate Language and The Zachman Framework.

What is the ArchiMate Language? Well, it’s a language we use for building understanding across disciplines in an organization and communicating and managing change.  It’s a graphical notation with formal semantics. It’s a language.

It’s a framework that describes and relates the business, application, and technology layers of an enterprise, and it has extensions for modelling motivation, which includes business strategy, external factors affecting the organization, requirements for putting them altogether and for showing them from different stakeholder perspectives.

You can show conflicting stakeholder perspectives, and even politics. I’ve used it to model organizational politics that were preventing a project from going forward.

It has a rich set of techniques in its viewpoint mechanism for visualizing and analyzing what’s going on in your enterprise. Those viewpoints are tailored to different stakeholders.  And, of course, ArchiMate®, like TOGAF®, is an open standard managed by The Open Group.

Taste of Archimate

This is just a taste of ArchiMate for people who haven’t seen it before. This is actually excerpted from the presentation my colleague Chris McCurdy and I are doing at this conference on Guiding Agile Solution Delivery with the ArchiMate Language.

What this shows is the Business and Application Layers of ArchiMate. It shows a business process at the top. Each process is represented by a symbol. It shows a data model of business objects, then, at the next layer, in yellow.

Below that, it shows a data model actually realized by the application, the actual data that’s being processed.

Below that, it shows an application collaboration, a set of applications working together, that reads and writes that data and realizes the business data model that our business processes use.

All in all, it presents a vision of an integrated project management toolset for a particular SDLC that uses the phases that you see across the top.

We are going to dissect this model, how you would build it, and how you would develop it in an agile environment in our presentation tomorrow.

I have done some analysis of The Zachman Framework, comparing it to the ArchiMate Language. What’s really clear is that ArchiMate supports enterprise architecture with The Zachman Framework. You see a rendering of The Zachman Framework and then you see a rendering of the components of the ArchiMate Language. You see the Business Layer, the Application Layer, the Technology Layer, its ability to express information, behavior, and structure, and then the Motivation and Implementation and Migration extensions.

So how does it support it? Well, there are two key things here. The first is that ArchiMate models answer the questions that are posed by The Zachman Framework columns.

For what: for Inventory. We are basically talking about what is in the organization. There are Business and Data Objects, Products, Contracts, Value, and Meaning.

For how: for process. We can model Business Processes and Functions. We can model Flow and Triggering Relationships between them.

Where: for the Distribution of our assets. We can model Locations, we can model Devices, and we can model Networks, depending on how you define Location within a network or within a geography.

For who: We can model Responsibility, with Business Actors, Collaborations, and Roles.

When: for Timing. We have Business Events, Plateaus of System Evolution, relatively stable systems states, and we have Triggering Relationships.

Why: We have a rich Motivation extension, Stakeholders, Drivers, Assessments, Principles, Goals, Requirements, etc., and we show how those different components influence and realize each other.

Zachman perspectives

Finally, ArchiMate models express The Zachman Row Perspectives. For the contextual or boundary perspective, where Scope Lists are required, we can make catalogs of ArchiMate Concepts. ArchiMate has broad tool support, and in a repository-based tool, while ArchiMate is a graphical language, you can very easily take list of concepts, as I do regularly, and put them in catalog or metrics form. So it’s easy to come up with those Scope Lists.

Secondly, for the Conceptual area, the Business Model, we have a rich set of Business Layer Viewpoints. Like the top of the — that focus on the top of the diagram that I showed you; Business Processes, Actors, Collaborations, Interfaces, Business Services that are brought to market.

Then at the Logical Layer we have System. We have a rich set of Application Layer Viewpoints and Viewpoints that show how Applications use Infrastructure.

For Physical, we have an Infrastructure Layer, which can be used to model any type of Infrastructure: Hosting, Network, Storage, Virtualization, Distribution, and Failover. All those types of things can be modeled.

And for Configuration and Instantiation, the Application and Technology Layer Viewpoints are available, particularly more detailed ones, but are also important is the Mappings to standard design languages such as BPMN, UML and ERD. Those are straightforward for experienced modelers. We also have a white paper on using the ArchiMate language with UML. Thank you.

By The Open GroupDr. Beryl Bellman: I have been doing enterprise architecture for quite a long time, for what you call pre-enterprise architecture work, probably about 30 years, and I first met John Zachman well over 20 years ago.

In addition to being an enterprise architect I am also a University Professor at California State University, Los Angeles. My focus there is on Organizational Communications. While being a professor, I always have been involved in doing contract consulting for companies like Digital Equipment Corporation, ASK, AT&T, NCR, then Ptech.

About 15 years ago, a colleague of mine and I founded the FEAC Institute. The initial name for that was the Federal Enterprise Architecture Certification Institute, and then we changed it to Federated. It actually goes by both names.

The business driver of that was the Clinger–Cohen Bill in 1996 when it was mandated by government that all federal agencies must have an enterprise architecture.

And then around 2000, they began to enforce that regulation. My business partner at that time, Felix Rausch, and I felt that we need some certification in how to go about doing and meeting those requirements, both for the federal agencies and the Department of Defense. And so that’s when we created the FEAC Institute.

Beginning of FEAC

In our first course, we had the Executive Office of the President, US Department of Fed, which I believe was the first Department of the Federal Government that was hit by OMB which held up their budget for not having an enterprise architecture on file. So they were pretty desperate, and that began the first of the beginning of the FEAC.

Since that time, a lot of people have come in from the commercial world and from international areas. And the idea of FEAC was that you start off with learning how to do enterprise architecture. In a lot of programs, including TOGAF, you sort of have to already know a little bit about enterprise architecture, the hermeneutical circle. You have to know what it is to know.

In FEAC we had a position that you want to provide training and educating in how to do enterprise architecture that will get you from a beginning state to be able to take full responsibility for work doing enterprise architecture in a matter of three months. It’s associated with the California State University System, and you can get, if you so desire, 12 graduate academic units in Engineering Management that can be applied toward a degree or you can get continuing education units.

So that’s how we began that. Then, a couple of years ago, my business partner decided he wanted to retire, and fortunately there was this guy named John Zachman, who will never retire. He’s a lot younger than all of us in this room, right? So he purchased the FEAC Institute.

I still maintain a relationship with it as Academic Director, in which primarily my responsibilities are as a liaison to the universities. My colleague, Cort Coghill, is sort of the Academic Coordinator of the FEAC Institute.

FEAC is an organization that also incorporates a lot of the training and education programs of Zachman International, which includes managing the FEAC TOGAF courses, as well as the Zachman certified courses, which we will tell you more about.

‘m just a little bit surprised by this idea, the panel, the way we are constructed here, because I didn’t have a presentation. I’m doing it off the top, as you can see. I was told we are supposed to have a panel discussion about the synergies of enterprise architecture. So I prepared in my mind the synergies between the different enterprise architectures that are out there.

For that, I just wanted to make a strong point. I wanted to talk about synergy like a bifurcation between on the one hand, “TOGAF and Zachman” as being standing on one side, whereas the statement has been made earlier this morning and throughout the meeting is “TOGAF and.”

Likewise, we have Zachman, and it’s not “Zachman or, but it’s ‘Zachman and.” Zachman provides that ontology, as John talks about it in his periodic table of basic elements of primitives through which we can constitute any enterprise architecture. To attempt to build an architecture out of composites and then venting composites and just modeling  you’re just getting a snapshot in time and you’re really not having an enterprise architecture that is able to adapt and change. You might be able to have a picture of it, but that’s all you really have.

That’s the power of The Zachman Framework. Hopefully, most of you will attend our demonstration this afternoon and a workshop where we are actually going to have people work with building primitives and looking at the relationship of primitives, the composites with a case study.

Getting lost

On the other side of that, Schekkerman wrote something about the forest of architectural frameworks and getting lost in that. There are a lot of enterprise architectural frameworks out there.

I’m not counting TOGAF, because TOGAF has its own architectural content metamodel, with its own artifacts, but those does not require one to use the artifacts in the architectural content metamodel. They suggest that you can use DoDAF. You can use MODAF. You can use commercial ones like NCR’s GITP. You can use any one.

Those are basically the competing models. Some of them are commercial-based, where organizations have their own proprietary stamps and the names of the artifacts, and the wrong names for it, and others want to give it its own take.

I’m more familiar nowadays with the governmental sectors. For example, FEAF, Federal Enterprise Architecture Framework Version 2. Are you familiar with that? Just go on the Internet, type in FEAF v2. Since Scott Bernard has been the head, he is the Chief Architect for the US Government at the OMB, he has developed a model of enterprise architecture, what he calls the Architecture Cube Model, which is an iteration off of John’s, but he is pursuing a cube form rather than a triangle form.

Also, for him the FEAF-II, as enterprise architecture, fits into his FEAF-II, because at the top level he has the strategic plans of an organization.

It goes down to different layers, but then, at one point, it drops off and becomes not only a solution, but it gets into the manufacturing of the solution. He has these whole series of artifacts that pertain to these different layers, but at the lower levels, you have a computer wiring closet diagram model, which is a little bit more detailed than what we would consider to be at a level of enterprise architecture.

Then you have the MODAF, the DoDAF, and all of these other ones, where a lot of those compete with each other more on the basis of political choices.

With the MODAF, the British obviously don’t want to use DoDAF, they have their own, but they are very similar to each other. One view, the acquisition view, differs from the project view, but they do the same things. You can define them in terms of each other.

Then there is the Canadian, NAF, and all that, and they are very similar. Now, we’re trying to develop the unified MODAF, DoDAF, and NAF architecture, UPDM, which is still in its planning stages. So we are moving toward a more integrated system.

BrownAllen Brown: Let’s move on to some of the questions that folks are interested in. Moving away from what the frameworks are, there is a question here. How does enterprise architecture take advantage of the impact of new emerging technologies like social, mobile, analytics, cloud, and so on?

Bidirectional change

John A Zachman: The change can take place in the enterprise either from the top, where we change the context of the enterprise, or from the bottom, where we change the technologies.

So technology is expressed in the context of the enterprise, what I would call Rule 4, and that’s the physical domain. And it’s the same way in any other — the building architecture, the airplane architecture, or anything. You can implement the logic, the as-designed logic, in different technologies.

Whatever the technology is, I made an observation that you want to engineer for flexibility. You separate the independent variables. So you separate the logic at Rule 3 from the physics of Rule 4, and then you can change Rule 4 without changing Rule 3. Basically that’s the idea, so you can accommodate whatever the emerging technologies are.

Bellman: I would just continue with that. I agree with John. Thinking about the synergy between the different architectures, basically every enterprise architecture contains, or should contain, considerations of those primitives. Then, it’s a matter of which a customer wants, which a customer feels comfortable with? Basically as long as you have those primitives defined, then you essentially can use any architecture. That constitute the synergy between the architectures.

Band: I agree with what’s been said. It’s also true that I think that one of the jobs of an enterprise architect is to establish a view of the organization that can be used to promote understanding and communicate and manage change. With cloud-based systems, they are generally based on metadata, and the major platforms, like Salesforce.com as an example. They publish their data models and their APIs.

So I think that there’s going to be a new generation of systems that provide a continuously synchronized, real-time view of what’s going on in the enterprise. So the architectural model will model this in the future, where things need to go, and they will do analyses, but we will be using cloud, big data, and even sensor technologies to understand the state of the enterprise.

Bellman: In the DoDaF 2.0, when that initially came out, I think it was six years ago or so, they have services architecture, a services view, and a systems view. And one of the points they make within the context, not as a footnote, is that they expect the systems view to sort of disappear and there will be a cloud view that will take its place. So I think you are right on that.

Chris Forde: The way I interpreted the question was, how does EA or architecture approach the things help you manage disruptive things? And if you accept the idea that enterprise architecture actually is a management discipline, it’s going to help you ask the right questions to understand what you are dealing with, where it should be positioned, what the risks and value proposition is around those particular things, whether that’s the Internet of Things, cloud computing, or all of these types of activities.

So going back to the core of what Terry’s presentation was about is a decision making framework with informed questions to help you understand what you should be doing to either mitigate the risk, take advantage of the innovation, and deploy the particular thing in a way that’s useful to your business. That’s the way I read the question.

Impact of sensors

Band: Just to reinforce what Chris says, as an enterprise architect in healthcare, one of the things that I am looking at very closely is the evaluation of the impact of health sensor technology. Gartner Group says that by 2020, the average lifespan in a developed country will be increased by six months due to mobile health monitoring.

And so there are vast changes in the whole healthcare delivery system, of which my company is at the center as a major healthcare payer and investor in all sorts of healthcare companies. I use enterprise architecture techniques to begin to understand the impact of that and show the opportunities to our health insurance business.

Brown: If you think about social and mobile and you look at the entire enterprise architecture, now you are starting to expand that beyond the limits of the organization, aren’t you? You’re starting to look at, not just the organization and the ecosystem, your business partners, but you are also looking at the impact of bringing mobile devices into the organization, of managers doing things on their own with cloud that wasn’t part of the architecture. You have got the relationship with consumers out there that are using social and mobile. How do you capture all of that in enterprise architecture?

Forde: Allen, if I had the answer to that question I would form my own business and I would go sell it.

Back in the day, when I was working in large organizations, we were talking about the extended enterprise, that kind of ecosystem view of things. And at that time the issue was more problematic. We knew we were in an extended ecosystem, but we didn’t really have the technologies that effectively supported it.

The types of technologies that are available today, the ones that The Open Group has white papers about — cloud computing, the Internet of Things, this sort of stuff — architectures can help you classify those things. And the technologies that are being deployed can help you track them, and they can help you track them not as documents of the instance, but of the thing in real time that is talking to you about what its state is, and what its future state will be, and then you have to manage that information in vast quantities.

So an architecture can help you within your enterprise understand those things and it can help you connect to other enterprises or other information sources to allow you to make sense of all those things. But again, it’s a question of scoping, filtering, making sense, and abstracting — that key phrase that John pointed out earlier, of abstracting this stuff up to a level that is comprehensible and not overwhelming.

Brown: So Iver, at Cambia Health, you must have this kind of problem now, mustn’t you?

Provide value

Band: That’s exactly what I am doing. I am figuring out what will be the impact of certain technologies and how our businesses can use them to differentiate and provide value.

In fact, I was just on a call this morning with JeffSTAT, because the whole ecosystem is changing, and we know that healthcare is really changing. The current model is not financially sustainable, and there is also tremendous amount of waste in our healthcare system today. The executives of our company say that about a third of the $2.7 trillion and rising spent on healthcare in the US doesn’t do anyone any good.

There’s a tremendous amount of IT investment in that, and that requires architecture to tie it altogether. It has to do with all the things ranging from the logic with which we edit claims, to the follow-up we provide people with particularly dangerous and consequently expensive diseases. So there is just a tremendous amount going through an enterprise architecture. It’s necessary to have a coherent narrative of what the organization needs to do.

Bellman: One thing we all need to keep in mind is even more dynamic than that, if you believe even a little bit of Kurzweil’s possibilities is that — are people familiar with Ray Kurzweil’s ‘The Singularity Is Near’ — 2037 will be around the singularly between computers and human beings.

So I think that the wrap where he argues that the amount of change is not linear but exponential, and so in a sense you will never catch up, but you need an architecture to manage that.

By The Open GroupZachman: The way we deal with complexity is through classification. I suggest that there is more than one way to classify things. One is one-dimensional classification, taxonomy, or hierarchy, in effect, decompositions, one-dimensional classification, and that’s really helpful for manufacturing. From an engineering standpoint of a two-dimensional classification, where we have classified things so that they are normalized, one effect in one place.

Then if you have the problems identified, you can postulate several technology changes or several changes and simulate the various implications of it.

The whole reason why I do architecture has to do with change. You deal with extreme complexity and then you have to accommodate extreme change. There is no other way to deal with it. Humanity, for thousands of years, has not been able to figure out a better way to deal with complexity and change other than architecture.

Forde: Maybe we shouldn’t apply architecture to some things.

For example, maybe the technologies or the opportunity is so new, we need to have the decision-making framework that says, you know what, let’s not try and figure out all this, just to self-control their stuff in advance, okay? Let’s let it run and see what happens, and then when it’s at the appropriate point for architecture, let’s apply it, this is a more organic view of the way nature and life works than the enterprise view of it.

So what I am saying is that architecture is not irrelevant in that context. It’s actually there is a part of the decision-making framework to not architect something at this point in time because it’s inappropriate to do so.

Funding and budgeting

Band: Yeah, I agree that wholeheartedly. If it can’t be health solutions, we are a completely agile shop. All the technology development is on the same sprint cycle, and we have three-week sprints, but we also have certain things that are still annual and wonderful like funding and budgeting.

We live in a tension. People say, well, what are you going to do, what budget do you need, but at the same time, I haven’t figured everything out. So I am constantly living in that gap of what do I need to meet a certain milestone to get my project funded, and what do I need to do to go forward? Obviously, in a fully agile organization, all those things would be fluid. But then there’s financial reporting, and we would also have to be fluid too. So there are barriers to that.

For instance, the Scaled Agile Framework, which I think is a fascinating thing, has a very clear place for enterprise architecture. As Chris said, you don’t want to do too much of it in advance.  I am constantly getting the gap between how can I visualize what’s going to happen a year out and how can I give the development teams what they need for the sprint. So I am always living in that paradox.

Bellman: The Gartner Group, not too long ago, came up with the concept of emerging enterprise architecture and what we are dealing with. Enterprises don’t exist like buildings. A building is an object, but an enterprise is a group of human beings communicating with one another.

As a very famous organizational psychologist Karl Weick once pointed out, “The effective organization is garrulous, clumsy, superstitious, hypocritical, mostrous, octopoid, wandering, and grouchy.” Why? Because an organization is continually adapting, continually changing, and continually adapting to the changing business and technological landscape.

To expect anything other than that is not having a realistic view of the enterprise. It is emerging and it is a continually emerging phenomena. So in a sense, having an architecture concept I would not contest, but architecting is always worthwhile. It’s like it’s an organic phenomena, and that in order to deal with that what we can also understand and have an architecture for organic phenomena that change and rapidly adapt.

Brown: Chris, where you were going follows the lines of what great companies do, right?

There is a great book published about 30 years ago called ‘In Search of Excellence.’ If you haven’t read it, I suggest that people do. Written by Peters and Waterman, and Tom Peters has tried for ever since to try and recreate something with that magic, but one of the lessons learned was what great companies do, is something that goes simultaneous loose-tight properties. So you let somethings be very tightly controlled, and other things as are suggesting, let them flourish and see where they go before I actually box them in. So that’s a good thought.

So what do we think, as a panel, about evolving TOGAF to become an engineering methodology as well as a manufacturing methodology?

Zachman: I really think it’s a good idea.

Brown: Chris, do you have any thoughts on that?

Interesting proposal

Forde: I think it’s an interesting proposal and I think we need to look at it fairly seriously. The Open Group approach to things is, don’t lock people into a specific way of thinking, but we also advocate disciplined approach to doing things. So I would susspect that we are going to be exploring John’s proposal pretty seriously.

Brown: You mentioned in your talk that decision-making process is a precondition, the decision-making process to govern IT investments, and the question that comes in is how about other types of investments including facilities, inventory and acquisitions?

By The Open GroupForde: The wording of the presentation was very specific. Most organizations have a process or decision-making framework on an annual basis or quarterly whatever the cycles are for allocation of funding to do X, Y or Z. So the implication wasn’t that IT was the only space that it would be applied.

However, the question is how effective is that decision-making framework? In many organizations, or in a lot of organizations, the IT function is essentially an enterprise-wide activity that’s supporting the financial activities, the plant activities, these sorts of things. So you have the P&Ls from those things flowing in some way into the funding that comes to the IT organization.

The question is, when there are multiple complexities in an organization, multiple departments with independent P&Ls, they are funding IT activities in a way that may not be optimized, may or may not be optimized. For the architects, in my view, one of the avenues for success is in inserting yourself into that planning cycle and influencing,  because normally the architecture team does not have direct control over the spend, but influencing how that spend goes.

Over time gradually improving the enterprise’s ability to optimize and make effective the funding it applies for IT to support the rest of the business.

Zachman: Yeah, I was just wondering, you’ve got to make observation.

Band: I agree, I think that the battle to control shadow IT has been permanently lost. We are in a technology obsessed society. Every department wants to control some technology and even develop it to their needs. There are some controls that you do have, and we do have some, but we have core health insurance businesses that are nearly a 100 years old.

Cambia is constantly investing and acquiring new companies that are transforming healthcare. Cambia has over a 100 million customers all across the country even though our original business was a set of regional health plans.

Build relationships

You can’t possibly rationalize all of everything I want you to pay for on that thing. It is incumbent upon the architects, especially the senior ones, to build relationships with the people in these organizations and make sure everything is synergetic.

Many years ago, there was a senior architect. I asked him what he did, and he said, “Well, I’m just the glue. I go to a lot of meetings.” There are deliverables and deadlines too, but there is a part of consistently building the relationships and noticing things, so that when there is time to make a decision or someone needs something, it gets done right.

Zachman: I was in London when Bank of America got bought by NationsBank, and it was touted as the biggest banking merger in the history of the banking industry.

Actually it wasn’t a merger, it was an acquisition NationsBank acquired Bank of America and then changed the name to Bank of America. There was a London paper that was  observing that the headline you always see is, “The biggest merger in the history of the industry.” The headline you never see is, “This merger didn’t work.”

The cost of integrating the two enterprises exceeded the value of the acquisition. Therefore, we’re going to have to break this thing up in pieces and sell off the pieces as surreptitiously as possible, so nobody will notice that we buried any accounting notes someplace or other. You never see that article. You’ll only see the one about the biggest merger.

If I was the CEO and my strategy was to grow by acquisition, I would get really interested in enterprise architecture. Because you have to be able to anticipate the integration of the cost, if you want to merge two enterprises. In fact, you’re changing the scope of the enterprise. I have talked a little bit about the role on models, but you are changing the scope. As soon as you change a scope, you’re now going to be faced with an integration issue.

Therefore you have to make a choice, scrap and rework. There is no way, after the fact, to integrate parts that don’t fit together. So you’re gong to be faced a decision whether you want to scrap and rework or not. I would get really interested in enterprise architecture, because that’s what you really want to know before you make the expenditure. You acquire and obviously you’ve already blown out all the money. So now you’ve got a problem.

Once again, if I was the CEO and I want to grow by acquisition or merger acquisition, I would get really interested in enterprise architecture.

Cultural issues

Beryl Bellman: One of the big problems we are addressing here is also the cultural and political problems of organizations or enterprises. You could have the best design type of system, and if people and politics don’t agree, there are going to be these kind of conflicts.

I was involved in my favorite projects at consulting. I was involved in consulting with NCR, who was dealing with Hyundai and Samsung and trying to get them together at a conjoint project. They kept fighting with each other in terms of knowledge management, technology transfer, and knowledge transfer. My role of it was to do an architecture of that whole process.

It was called RIAC Research Institute in Computer Technology. On one side of the table, you had Hyundai and Samsung. On the other side of the table, you had NCR. They were throwing PowerPoint slides back and forth at each other. I brought up that the software we used at that time was METIS, and METIS modeled all the processes, everything that was involved.

Samsung said you just hit it with a 2×4. I used to be demonstrating it, rather than tossing out slides, here are the relationships, and be able to show that it really works. To me that was a real demonstration that I can even overcome some of the politics and cultural differences within enterprises.

Brown: I want to give one more question. I think this is more of a concern that we have raised in some people’s minds today, which is, we are talking about all these different frameworks and ontologies, and so there is a first question.

The second one is probably the key one that we are looking at, but it asks what does each of the frameworks lack, what are the key elements that are missing, because that leads on to the second question that says, isn’t needing to understand old enterprise architecture frameworks is not a complex exercise for a practitioner?

Band: My job is not about understanding frameworks. I have been doing enterprises solution architecture in HP at a standard and diversified financial services company and now at health insurance and health solutions company out for quite a while, and it’s really about communicating and understanding in a way that’s useful to your stakeholders.

The frameworks about creating shared understanding of what we have and where are we going to go, and the frameworks are just a set of tools that you have in your toolbox that most people don’t understand.

So the idea is not to understand everything but to get a set of tools, just like a mechanic would, that you carry around that you use all the time. For instance, there are certain types of ArchiMate views that I use when I am in a group. I will draw an ArchiMate business process view with application service use of the same. What are the business processes you need to be and what are the exposed application behaviors that they need to consume?

I had that discussion with people on the business who are in IT, and we drove those diagrams. That’s a useful tool, it works for me, it works for the people around me, it works in my culture, but there is no understanding over frameworks unless that’s your field of study. They are all missing the exact thing you need for a particular interaction, but most likely there is something in there that you can base the next critical interaction on.

Six questions

Zachman: I spent most of my life thinking about my frameworks. There are six questions you have to answer to have a complete description of whatever it is, what I will describe, what, how, where, who, and why. So that’s complete.

The philosophers have established six transformations interestingly enough, the transfer of idea into an instantiation, so that’s a complete set, and I did not invent either one of these, so the six interrogatives. They have the six stages of transformation and that framework has to, by definition, accommodate any factor that’s relevant to the existence of the object of the enterprise.  Therefore any fact has to be classifiable in that structure.

My framework is complete in that regard. For many years, I would have been reluctant to make a categorical statement, but we exercised this, and there is no anomaly. I can’t find an anomaly. Therefore I have a high level of confidence that you can classify any fact in that context.

There is one periodic table. There are n different compound manufacturing processes. You can manufacture anything out of the periodic table. That metaphor is really helpful. There’s one enterprise architecture framework ontology. I happened to stumble across, by accident, the ontology for classifying all of the facts relevant to an enterprise.

I wish I could tell you that I was so smart and understood all of these things at the beginning, but I knew nothing about this, I just happened to stumble across it. The framework fell on my desk one day and I saw the pattern. All I did was I put enterprise names on the same pattern for descriptive representation of anything. You’ve heard me tell quite a bit of the story this afternoon. In terms of completeness I think my framework is complete. I can find no anomalies and you can classify anything relative to that framework.

And I agree with Iver, that there are n different tools you might want to use. You don’t have to know everything about every framework. One thing is, whatever the tool is that you need to deal with and out of the context of the periodic table metaphor, the ontological construct of The Zachman Framework, you can accommodate whatever artifacts the tool creates.

You don’t have to analyze every tool, whatever tool is necessary, if you want to do with business architecture, you can create whatever the business architecture manifestation is. If you want to know what DoDAF is, you can create the DoDAF artifacts. You can create any composite, and you can create any compound from the periodic table. It’s the same idea.

I wouldn’t spend my life trying to understand all these frameworks. You have to operate the enterprise, you have to manage the enterprise and whatever the tool is, it’s required to do whatever it is that you need to do and there is something good about everything and nothing necessarily does everything.

So use the tool that’s appropriate and then you can create whatever the composite constructs are required by that tool out of the primitive components of the framework. I wouldn’t try to understand all the frameworks.

What’s missing

Forde: On a daily basis there is a line of people at these conferences coming to tell me what’s missing from TOGAF. Recently we conducted a survey through the Association of Enterprise Architects about what people needed to see. Basically the stuff came back pretty much, please give us more guidance that’s specific to my situation, a recipe for how to solve world hunger, or something like that. We are not in the role of providing that level of prescriptive detail.

The value side of the equation is the flexibility of the framework to a certain degree to allow many different industries and many different practitioners drive value for their business out of using that particular tool.

So some people will find value in the content metamodel in the TOGAF Framework and the other components of it, but if you are not happy with that, if it doesn’t meet your need, flip over to The Zachman Framework or vice versa.

John made it very clear earlier that the value in the framework that he has built throughout his career and has been used repeatedly around the world is its rigor, it’s comprehensiveness, but he made very clear, it’s not a method. There is nothing in there to tell you how to go do it.

So you could criticize The Zachman Framework for a lack of method or you could spend your time talking about the value of it as a very useful tool to get X, Y, and Z done.

From a practitioner’s standpoint, what one practitioner does is interesting in a value, but if you have a practice between 200 and 400 architects, you don’t want everybody running around like a loose cannon doing it their way, in my opinion. As a practice manager or leader you need something that makes those resources very, very effective. And when you are in a practice of that size, you probably have a handful of people trying to figure out how the frameworks come together, but most of the practitioners are tasked with taking what the organization says is their best practice and executing on it.

We are looking at improving the level of guidance provided by the TOGAF material, the standard and guidance about how to do specific scenarios.

For example, how to jumpstart an architecture practice, how to build a secure architecture, how to do business architecture well? Those are the kinds of things that we have had feedback on and we are working on around that particular specification.

Brown: So if you are employed by the US Department of Defense you would be required to use DoDAF, if you are an enterprise architect, because of the views it provides. But people like Terri Blevins that did work in the DoD many years, used TOGAF to populate DoDAF. It’s a method, and the method is the great strength.

If you want to have more information on that, there are a number of white papers on our website about using TOGAF with DoDAF, TOGAF with COBIT, TOGAF with Zachman, TOGAF with everything else.

Forde: TOGAF with frameworks, TOGAF with buy in, the thing to look at is the ecosystem of information around these frameworks is where the value proposition really is. If you are trying to bootstrap your standards practice inside, the framework is of interest, but applied use, driving to the value proposition for your business function is the critical area to focus on.

The panel, which examined the synergy among the major EA frameworks, consists of moderator Allen Brown, President and Chief Executive Officer, The Open Group; Iver Bank, an Enterprise Architect, Cambia Health Solutions; Dr. Beryl Bellman, Academic Director, FEAC Institute; John Zachman, Chairman and CEO of Zachman International, and originator of the Zachman Framework; and Chris Forde, General Manager, Asia and Pacific Region and Vice President, Enterprise Architecture, The Open Group.

Transcript available here.

Join the conversation @theopengroup #ogchat

You may also be interested in:

 

2 Comments

Filed under ArchiMate®, big data, Business Architecture, Cloud, Data management, Enterprise Architecture, Enterprise Transformation, Standards, TOGAF®, Uncategorized

“Lean” Enterprise Architecture powered by TOGAF® 9.1

By Krish Ayyar, Managing Principal, Martin-McDougall Technologies

Enterprise Architecture is there to solve Enterprise level problems. A typical problem scenario could be something like “A large Mining and Resources company uses many sensors to collect and feed engineering data back to the central control room for monitoring their assets. These sensors are from multiple vendors and they use proprietary networking technologies and also data formats. There are interoperability issues. The company would like to improve the manageability and availability of these systems by exploring solutions around the emerging Internet Of Things (IoT) technology”.

There are many ways to solve Enterprise level problems. A typical approach might be to purchase a packaged software or develop bespoke solutions and sponsor an IT project to implement it.

So, what is special about Enterprise Architecture? EA is the only approach that puts you in the driver seat when it comes to orderly evolution of your enterprise’s business and information systems landscape.

How do we go about doing this?

The best way is to develop Enterprise Architecture in a short engagement cycle of say 4 to 6 weeks through the use of TOGAF® 9.1 method. If you think about it, the TOGAF® ADM basically covers 4 “Meta” phases. They are namely: Preparing and Setting the Architecture Vision, Blueprinting the Target State, Solutioning & Road Mapping, Governance and Change Management. The key to a short engagement cycle is in not doing those activities which are already done elsewhere in the organisation but linking with them. This includes Business Strategy, IT Strategy, Detailed Implementation Planning and Governance. This might mean “Piggy Backing” on PMO processes and extending them to include Enterprise Architecture.

As part of “Preparing and Setting the Architecture Vision”, we identify the Business Goals, Objectives and Drivers related to this problem scenario. For instance in this case, let us say we ran business scenario workshops and documented the CFO’s statement that the overall cost of remotely monitoring and supporting Engineering Systems must come down. We now elicit the concerns and requirements related to business and information systems from the stakeholders. In this case, the CEO has felt that the company needs new capabilities for monitoring devices anytime, anywhere.

As part of the “Governance and Change Management”, we look at emerging Business and Technology trends. Internet of Things or “IoT” is trending as the technology which has the ability to connect sensors to the internet for effective control. At this juncture, we should do some research and collect information about the Product and Technology Solutions that could deliver the new or enhanced capabilities. Major vendors such as SAP, Cisco and Microsoft have IoT Solutions in their offerings. These solutions are capable of enabling remote support using mobile devices streaming data in the cloud, network infrastructure for transporting the data using open standards, Cloud Computing, sensor connectivity to Wifi / Internet etc.,

Next, as part of “Blueprinting the Target State””, we model the Current and Target state Business Capabilities and Information System Services and Functionalities. We can do this very quickly by selecting the relevant TOGAF® 9.1 Artifacts to address the concerns and requirements. These are grouped by Architecture Domains within the TOGAF® 9.1 document. We then identify the Gaps. In our example, these could be new support capabilities using IoT.

Now as part of “Solutioning and Road Mapping”, we roadmap the gaps in a practical way to deliver business value. We could effectively use the TOGAF® 9.1 “Business Value Assessment” technique to achieve this. This will help us to realise the business goals and objectives as per business priorities delivered by the solution components. For example, reducing the cost of remotely monitoring and supporting engineering systems could be realised by solutions that enable remote monitoring and support using mobile devices streaming data in the cloud.

Of course, architecture work is not complete until the solution is architected from a design perspective to manage the product and technology complexities during implementation. There is also the need for Architecture Governance to ensure that it does not go pear-shaped during implementation and operation.

This does not seem to be a lot of effort, does it? In fact, some sort of conceptualisation happens in all major projects prior to the business case leading up to funding approval. When it is done by people who do not have the right mix of strategy, project management, solutioning and consulting skills, it becomes a mere “tick in the box” exercise. Why not adopt this structured approach of Enterprise Architecture powered by TOGAF® 9.1 and reap the rewards?

By Krish Ayyar, Martin-McDougall TechnologiesKrish Ayyar is an accomplished Enterprise Architecture Practitioner with well over 10 years consulting and teaching Enterprise Architecture internationally. He is a sought after Trainer of TOGAF® 9.1 Level 2 and Archimate® 2.1 Level 2 Certification Courses with teaching experience for over 5 years in Australia, New Zealand, China, Japan, India, USA and Canada.  His experience includes a background in management consulting with Strategy and Business Transformation consulting, Enterprise Architecture consulting and Enterprise Architect functional roles in Australia, Singapore, Malaysia and USA for over 15 years. Krish is an active contributor to The Open Group Architecture Forum activities through membership of his own consulting company based in Sydney, Australia.  Krish has been a presenter in Open Group conferences at Boston, Washington D.C and Sydney. He is currently Vice Chair of the Certification Standing Committee of the Architecture Forum.

 

 

Comments Off on “Lean” Enterprise Architecture powered by TOGAF® 9.1

Filed under ArchiMate®, Business Architecture, Certifications, Enterprise Architecture, Professional Development, Standards, TOGAF®, Uncategorized