This is DaveHornford's Typepad Profile.
Join Typepad and start following DaveHornford's activity
Join Now!
Already a member? Sign In
Recent Activity
Adrian, Been delayed: work & my life intruded. In the process of keeping the conversation focused I see two threads: requirements and contents of a framework. First Framework - It appears you are aligning all of TOGAF with one of its parts - the ADM. Roughly TOGAF has three parts: EA Capability, EA Method & EA Contents (these are my words and I'm generally unwilling to debate the which term is better) Within the EA Method there is a need to address development, consumption and life-cycle. In TOGAF 9.1 these are are addressed by the ADM and Governance Framework. This is the most developed part. EA Capability addresses purpose, process, team, organization, skills, value, etc.... In TOGAF 9.1 there are a number of these elements, which frankly are improved upon with work done after TOGAF 9 in the World Class EA Whitepaper series. Third EA Contents. In my opinion, TOGAF 9.1 has serious terminology drift in this part and uses the terms content framework and content meta-model as synonyms, when the content framework is a superset. This conceptual structure recognizes there is a need for contents that describe an architecture and surround an architecture. If I followed, most of what you identified as an EA framework aligns with this part of TOGAF - a set of models that describe an architecture. By explicit design this part is the most easily replaced part of TOGAF. There are a number of sets of excellent models to describe an architecture. I have not seen one set of models and associated viewpoints that will work for everyone: for defense, government, financial services, packaged goods, retail & resources. Especially, given diversity driven different purposes, archetypes or schools of EA. My team doesn't use TOGAF's content framework. We use the rest of TOGAF, but this part doesn't align to the problems we normally address. We call the set of tools we use Navigate. Simple customization for purpose, keep the baby & replace the bathwater. Moving to requirements. I'm quite intrigued about your issue with requirements at the centre of the ADM graphic. The ADM speaks to method not structure, and the graphic is descriptive. If I followed, the issue is traceability of architecture decision from strategy. In this case we need to look to the meta-model in TOGAF 9 (mostly chapter 34). The meta-model has no clear statement "strategy". Without any question this is an issue. I work around a broad concept of strategy and finding the set of motivations, goals, objectives and requirements necessary to realize the 'plan of action or policy designed to achieve a major or overall aim'. Regards Dave
Tom, We all have to do the math. My consulting firm just has double-digit staff and operates in 3 locations (Calgary, Ottawa, New York). Our total bill for participating in the Open Group greatly exceeds the price of a silver membership. Before putting myself forward for election as Chair, we had a hard conversation about investment & return. The same conversation we have about participating in any project at the Open Group. Attending the meetings requires travel & accommodation, time away from billable work, and then more time away from work when participating between the conferences. And, the cost of contributing hard-won IP to a common pool. Which gets to value. Frankly, the most significant value I get out of participation is the informal education when chasing out details with my peers. As an example, I spend 1/2 my billable time helping organizations stand-up or improve their in-house EA Capability. At the last meeting I led a workshop with 23 participants from other organizations (service provider & customer) on this topic. The process of exploring best practice was immediately beneficial to me & my firm. We were able to test our approach, and learn from others. In return, we taught, contributed IP as well as spending time and money. As an aside, the number one thing I have learned is to be very aware of my magical terms, where I have embedded special significance and meaning. For every one of my magical terms I can think of a peer who applies the same special significance and meaning to a different magical term.
@AdrianGrigoriu Third, adopting single models. This can be a conversation - structure I can explain, but we can't change how TOGAF is created. I am working on the next release and am interested in learning. In fact the trade-off this evening was a draft of TOGAF or replying. Here, even thought I have not had the opportunity to look at your suggested models, I suspect we will part company. I am inherently suspicious of the perfect model – and run two tests in my head: How about defense, government, financial services, packaged goods, retail & resources? What about coverage for different purposes, archetypes or schools of EA? If it misses one or more, it is not fit for everyone, regardless of fit for some. TM Forum has a rich set of models in Frameworx I have used in telecommunications and banking; DODAF has a specific set of models I have used in defense, oil & gas, electrical utility and public sector; FEAF has a set of mandated models; Canada’s Government Services Reference Model (GSRM) is one of the best service reference models I have used. I can go on. We can all go on. In my experience, most of us specialize and absorb the inherent foundation of our specialization as universal constructs. I believe that TOGAF needs to support rich domain, purpose or organizational, specific approaches. Without, favoring or constraining one, or another, rich approach. Today, I believe it is unnecessarily hard to utilize the available richness because we have confused a specific instantiation, or specific concept for a universal concept. My real problem is a current 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. When I look at TOGAF’s content meta-model and partially associated viewpoint library there are significant gaps between what is there and what I need: however useful an application/data matrix usually is I have a problem that needs to be addressed before one of these is useful.
@AdrianGrigoriu If we are to converse we may need to narrow the field. I’ll start on on three points structure, extending TOGAF and a single model. The latter is most interesting to me. First, structure - I have no idea how the TM Forum works so I cannot compare Chief Architect of TM Forum's Frameworx with my role in the Architecture Forum. The Open Group is a consortia of member companies who join, and participate in one or more Forums. My company, Conexiam, is a member. Chair of the Architecture Forum is a volunteer position. Annually elected by the members of the Architecture Forum. I have a limited ability to lead. Everything we do is by consensus. I even need approval at the quarterly member meeting of the agenda. In the projects I have one voice – in fact one of my participation values is testing my experience with my peers. TOGAF is a standard published by the Open Group, created through the Open Group's standards process. The core is member consensus about member work. Sadly, Newport Beach wasn't sunny on the two days my consulting commitments allowed me to attend. The upside, the members represent a very board range of industries, regions, and approaches. I am comfortable when we send a draft of TOGAF to some 3,000 people on the Architecture Forum mailing list, many of whom represent more people, we are hitting a significant cross section. Last time, we got more than 500 substantive comments. Are we hitting everyone possible? No. Frankly, I don’t lose any sleep. The downside is significant. People outside the process don’t understand it. Like Mike, they try and talk to ‘The Open Group’. In this blog, Mike invited people into the process. A few years ago I invited him to attend the framing meeting for the next release of TOGAF and represent his own ideas. While we are all influenced by our experience and learning, a member had to carry the influence in. We also do everything under non-disclosure. Second, extending. Since I have been Chair we worked consistently on integration and extension. The Architecture formally created joint projects with TM Forum, SABSA, BAIN, DAIMA, DODAF and interestingly the Open Group's SOA Work Group, Cloud Work Group, Security Forum, Real-time & Embedded Systems Forum & Archimate Forum. The last five may sound odd, but every Forum or Work Group is an independent entity under the umbrella of the Open Group, and has a different set of members. Staying with TM Forum, SABSA and BAIN (the whitepapers are published and available) Our intention was three-fold: - clarify how the special needs of telecommunication, enterprise security and financial services are served with a general purpose framework. We use a clear phrase 'TOGAF and'. A general-purpose framework should not have the depth, specificity and richness of a focused body of work. - extend TOGAF without the Architecture Forum having to pretend it knew everything and wrote everything - informally, learn where TOGAF may have used unduly specific concepts where a general purpose concept could allow the specialist's richness and specificity. What I personally took away from the work and conversations, and from my work enabling effective EA teams as a consultant informed my proposal on the next release of TOGAF. I saw a need for TOGAF to be conceptually clear, internally consistent, easier to consume and easier to extend; for the framework to be separated from guidance on how to use it.
Continued 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. 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. Sunday January 23rd at the Open Group's Newport Beach conference, I had 23 people from 3 continents in a workshop looking at EA Capability - we started at 9:00 AM. I look forward to seeing you at the next member meeting or a TOGAF next release call (your employer must be a member of the Open Group). Dave Dave Hornford @davehornford Enterprise Architect Managing Partner, Conexiam Chair, Open Group Architecture Forum
@AdrianGrigoriu @Mike I'll join the conversation - First a disclosure - I'm one of the people who wrote the tome. My fingerprints are all over TOGAF 9.1. I'm Chair of the Open Group Architecture Forum (the body that author's TOGAF), worked on TOGAF 9, worked very hard on the team that created TOGAF 9.1, have worked on most of the integration whitepapers released in the last few years, and am very active on the next release of TOGAF. So, I'll start - TOGAF doesn't suck. 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. Now a few points that rattled my cage: 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. Now, doing EA - I can see the point of Phase A, E, F, G & H. 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. 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. continued
Mike, In the past couple of years we have worked on a series of integration or interoperability whitepapers instead of simple mappings - SABSA/TOGAF, TMForum Frameworx, DODAF 2 and BIAN (Banking Industry Architecture Network). The integration approach is aimed at clarifying how you take the best. The root of this work was the Open Group's SOA/TOGAF Practical Guide
DaveHornford is now following The Typepad Team
Feb 11, 2013