Dave Hornford Addresses Misconceptions Surrounding TOGAF

 Mike The Architect Blog

I have gotten a surprising (or maybe not so surprising) discussion on the TOGAF Demystification Series. In one of the posts entitled, “TOGAF Demystification Series: TOGAF Sucks, Incomplete And Overly Complex” there were many comments made about this one in particular. All of the comments made for an interesting conversation but I did like the thoroughness of one in particular. I thought Dave Hornford made some extremely salient points and provided a bit of context from the perspective of the Chair of the TOGAF standard.

Since these great responses were buried in a comment thread I decided that it would be beneficial to all of you to promote this to a post as well given the meaningful content.

Note: For extended context click on the link above to see the full context of the responses. I have left comments unedited. 

 

Mike The Architect Blog: Dave HornfordDave Hornford Addresses Misconceptions Surrounding TOGAF

Dave Hornford is a Managing Partner for Conexiam as well as the Chair for the Open Group Architecture Forum (TOGAF)

 

Addressing comments about the quality of TOGAF

Is it as good as I want it to be, not a chance. Can I change it? Of course, all I have to do is obtain a consensus of a project team. The Architecture Forum then reviews this consensus, and then the member companies of the Open Group review it. At every point comments, concerns, objections & improvements must be addressed by consensus. I live Mike’s challenge.

In response to a misunderstanding of how TOGAF is applied and the meaning behind Requirements Phase in TOGAF

I do not understand the charge that TOGAF fails because it focuses on requirements? All I can assume is that special meaning is carried into TOGAF. Wherever possible in TOGAF we try to use a concept that can carry a range of specific detail – requirements is one of my favorite examples. TOGAF defines requirement as “a statement of need that must be met by a particular architecture or work package”.

TOGAF’s requirements are a nice broad concept – a statement of need that must be met by the architecture. What else an I going to find in the strategy, goals, objectives, hopes, fears, dreams, courses of action, and constraints other than requirements? The set of needs that must be met by the architecture.

Further, no weaseling in TOGAF. If we follow the thread in requirements & stakeholders, TOGAF highlights that best practice is provide a name. No hiding behind vague assertions like ‘shareholder value’, or ‘the strategy’. Instead we take those requirements and trace them back to a stakeholder. Show me who wants something and then I can perform trade-off between that stakeholder’s requirements and the requirements of the other stakeholders. I can weigh, assess, rank, and refine. And following best practice: review with my stakeholders and use the governance process to provide assurance. My only escape from this tyranny is to get one-or-more stakeholder’s to change the requirement, at which point I have a different set that must be met. No wonder TOGAF talks about iteration.

Doing real architecture is hard because of this point – it must address the complete set of requirements. No hiding. Get out in the open and show your work. Describe a target that best addresses the complete set of requirements and deliver a roadmap that will move the organization from where it is to where it wants to be within the capability of the organization to change. (Phase A, B, C, D, E & Requirements Management)

Second, I cannot see how TOGAF’s ADM can be considered a solution approach. If I’m doing solution architecture why would I develop an Architecture Vision (Phase A), develop a Roadmap (Phase E) then integrate the Implementation & Migration Plan into the organization’s portfolio (Phase F) and manage the lifecycle of my architecture (Phase H). I’ve heard many ways people wrap a solution approach, complete with proof-of-concept and RFPs into the ADM. But, in my opinion it’s a stretch.

 

Dave’s usage of TOGAF in his engagements

Do TOGAF or do EA? Sorry I don’t do TOGAF. I get paid to either deliver useful architecture or improve the capability of an EA team. TOGAF is a tool, not a goal. It is an EA Framework that provides scaffolding for capability, content & method. To quote TOGAF Part I, “the purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy”

In my opinion, too many words. In essence darned good – optimize across the enterprise the activity of the enterprise to create an integrated environment that is agile and supports current strategy… That’s worth getting out of bed for.

 

Addressing TOGAF and ArchiMate linkages

Lastly, you contend TOGAF fails because it isn’t hand-in-glove with Archimate. Here, I may run into trouble at the next set of member meetings. Archimate is a subset of the concepts required to completely describe an enterprise architecture.

This is not a slur on Archimate, by being a subset it allows me to use a reasonable set of entities, perform traceability between the entities and have a graphical notation I can learn quickly. Beautiful. Truly beautiful.

But, if I need to describe organizational culture, fully map strategy, associate capital allocation, participation of multiple third parties, return on equity and taxation, identify information entities by provenance & usage restriction, clouds and account for last mile connectivity to a specific restricted platform – I may find Archimate limited. When I pull out the complete set of modeling techniques to describe these entities I may have the richness of a 1/2 dozen domain specific modeling techniques and have to perform acrobatics to link them. There never is a free lunch. Don’t forget, I enjoy aerobatics.

When I do EA I need the freedom to describe what I need to describe to address the problem at hand – I will never let the toolset be constrained to a general-purpose saw. Sometimes a spoke shave, or coping saw or Mintzburg’s Organigraphs are needed. By the same token, I am very glad that I have a general-purpose tool that works reasonably well most of the time.

TOGAF aligns to my need for freedom and my expectation for a comprehensive toolset – there is a reasonable content-meta-model that provides a reasonable set of entities. I can read the mapping papers to Archimate. Or, I can roll my own and use Mintzburgh’s Organigraphic, Osterwalder’s Business Model Canvas & the OMG’s Business Motivation Model: exquisite richness and an integration challenge. Clearly a job for daveML. Or, use Archimate, and have a reasonable set that provides pre-defined end-to-end traceability. TOGAF is clear, use the tool needed. Describe what is necessary to understand, create a target that meets the set of stakeholder requirements, create a roadmap to traverse the gap and govern the builders to keep them on the path of goodness.

Regardless of my tooling, if I have the elements of TOGAF calls for – governance, appropriate team, integration with corporate process, consistent method to develop an architecture & roadmap, stakeholders and requirements I have the underpinning to create a very good understanding of how the enterprise ‘works’. Then I can do my job and optimize the future against the complete set of requirements. Good thing TOGAF is general purpose and provides a scaffold so I can address the problem I have in a manner consistent with the guy in the next office. When we use a minimum set of consistent entities we can even use each other’s work – although the guy in the next office does look askance at Organigraphics and Goal Structuring Notation.

I’d be happier if TOGAF was crisp on the distinction between concept and instantiation. Today I sometimes read an instantiation and have to derive the concept so I can re-instantiate appropriate to my problem. Perhaps the next release will make me happier.

 

Call to Action

I’ll re-iterate Mike’s challenge. Want to make the EA world better, join us in the Architecture Forum. But, be prepared to work to consensus with many of the world’s leading practitioners. It’s a tough crowd. Specialist boutique consultants, global consulting practices and some of the most advanced in-house architects will review your work. You will be challenged to find what consistently works for a very broad set of problems. Not just mine, or yours, or Mike’s.

 

You can find out more about Dave Hornford at:

@davehornford
http://www.conexiam.com

 

EA Effectiveness Series: Highly Impactful EA Organizations Make Value Driven Decisions

Mike The Architect Blog: Value Driven Decisions

A big thank you to all the folks that came to my presentation at the Troux World Conference last week. We had a full room of enterprise architects and EA consultants. Thank you for all your support and great questions. 

I wanted to  share with all of you my presentation given at the conference. Just like with most of my presentations there are lots of images that require a voice over. So, my apologies to those who are seeing this for the first time without hearing it in person. To remedy that a bit, I will post about the concepts form within the presentation over the course of the next few weeks . 

 

 

Summary

Enterprise Architects are faced with a rapidly changing business climate, competitive pressures and a shifting technology landscape that is forcing the enterprise to evolve. With this acceleration of change in the market it requires faster decisions that are well informed to maximize value. Enterprise Architects are at the tip of the spear to enable this change but need the tools.

In this session I will explore one of the proven practices that I have found from highly impactful Enterprise Architecture (EA) organizations, namely enterprise portfolios. Enterprise portfolios extend past the traditional project and program discipline to cover all aspects of the enterprise. Moving from disconnected, static and context-less pieces of data to a governed portfolio of enterprise knowledge that can maximize value and mitigate risk to our businesses.

 

Come See Mike Walker Speak on the EA Industry Expert Panel and Present at the Troux Conference 2013

Troux WWC 2013

The Troux Worldwide Conference is returning to Austin, Texas on March 19-20, 2013. If you are a Troux customer, partner, or actively involved in Enterprise Architecture (EA) or Enterprise Portfolio Management (EPM), this is your opportunity to enjoy peer networking and joint learning with a focus on delivering rapid results with Troux EPM solutions.

Mike Walker Troux Conference

I’m flattered and feel very fortunate to be invited back to speak on the EA Industry Expert Panel for a third year in a row! This is certainly an honor and I thank Troux for the opportunity to be invited back to this exclusive event each year. I especially am humbled to be surrounded by a great line up of speakers and EA practitioners. 

It should be a great event!

If there are folks that are the conference or in the Austin area that want to meet up to discuss EA please let me know either through the comments on this post or through Twitter. 

 You can see me in two sessions:

  1. Presentation – Highly Impactful EA Organizations Make Value Driven Decisions
  2. EA Industry Expert Panel – Success in the Connected Enterprise
 
Below I have provided the descriptions of each:

Highly Impactful EA Organizations Make Value Driven Decisions
Enterprise Architects are faced with a rapidly changing business climate, competitive pressures and a shifting technology landscape that is forcing the enterprise to evolve. With this acceleration of change in the market it requires faster decisions that are well informed to maximize value. Enterprise Architects are at the tip of the spear to enable this change but need the tools.

In this session I will explore one of the proven practices that I have found from highly impactful Enterprise Architecture (EA) organizations, namely enterprise portfolios. Enterprise portfolios extend past the traditional project and program discipline to cover all aspects of the enterprise. Moving from disconnected, static and context-less pieces of data to a governed portfolio of enterprise knowledge that can maximize value and mitigate risk to our businesses.

Success in the Connected Enterprise

Success in the connected enterprise requires that executives understand the cause-effect relationships that exist across their organization. They must know what can and should change, when to change it, and where to take risks, all while avoiding unintended consequences. Transforming people, product and processes is difficult, but it is even harder without having access to detailed and reliable knowledge about how the parts of their organizations fit together, operate and evolve. In this session our panelists will share their personal insights, and answer your questions, on how they use various portfolio concepts to navigate and guide critical decision-making in their organizations

EA Panel on Big Data and Cloud Trends Enabled by ArchiMate and TOGAF

I had had the pleasure of being on a panel of Enterprise Architecture (EA) experts at The Open Group Conference in Newport Beach, California. We were assembled to discuss complex trends such as big data, Cloud Computing, security, and overall IT transformation and how it can be enabled by The Open Group Architecture Framework (TOGAF®) and the ArchiMate® modeling language.

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

A big thanks to our moderator Dana Gardner from Interarbor Solutions.

See below for the key excerpts:

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

Listen to the podcast. Find it on iTunes. Read on the Open Group Blog,  full transcript or download a copy. 

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

Dana Gardner



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

Mike Walker

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

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

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

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

Not standalone

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

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

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

Band Iver

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

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

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

Hornford

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

 

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

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

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

 

Minor upgrade

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

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

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

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

Franken Henry

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

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

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

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

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

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

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

Least matured

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

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

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

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

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

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

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

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

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

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

 

Big business

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

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

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

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

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

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

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

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

 

Creating cadres

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

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

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

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

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

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

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

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

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

 

Quality of the individuals

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

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

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

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

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

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

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

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

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

 

Business context

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