Aggregated enterprise architecture wisdom
The following post is an extract from my draft eBook Business Architecture Viewpoints, available from @LeanpubThere are some things I don’t regard as part of the Business Architecture but as part of some other domain. One reason for these exclusions is…
<p><span style=”font-size: 11px; line-height: 19px;”>What interests me is that in many cases success in our work is not about the content per se (see </span><a style=”font-size: 11px; line-height: 19px;” title=”From Business Design to business Change” href=”http://www.bizzdesign.com/blog/from-business-design-to-business-change-1-the-content-paradox/#Blog series: business design to business change”>post #1 </a><span style=”font-size: 11px; line-height: 19px;”>of this series). Let me start this blog by recommending a somewhat strange, but brilliant and award winning movie ‘</span><a style=”font-size: 11px; line-height: 19px;” title=”1999 American comedy-fantasy film written by Charlie Kaufman and directed by Spike Jonze” href=”http://en.wikipedia.org/wiki/Being_John_Malkovich”>Being John Malkovich</a><span style=”font-size: 11px; line-height: 19px;”>’. It is – quite literally – about entering the head of John Malkovich. This is exactly what I try to keep in mind when meeting new clients. Seeing reality through John’s eyes. It became my associative reminder: “Be John Malkovich, be </span><em style=”font-size: 11px; line-height: 19px;”>[Client’s Name]</em><span style=”font-size: 11px; line-height: 19px;”>! “.</span></p><p><span style=”font-size: 11px; line-height: 19px;”> </span></p><div class=”captionImage left” style=”width: 214px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Being-john-malkovich.png” alt=”Being John Malkovich” title=”There is not one reality” width=”214″ height=”317″/><p class=”caption”>Be aware of the subjective reality in business change</p></div><p> </p><p><span style=”font-size: 11px; line-height: 19px;”>Although of interest, I do not just mean diving into the requirements regarding my client’s business problem – this is all content. What I mean is taking it a step further. What drives my client? What are his/her fears or frustrations? What are his/her shortcomings? What is the meaning of this context for my design approach? I have experienced that having a somewhat deeper understanding of my client’s pain and gain (see below) pays off. It has improved my approach towards a business solution and has helped me gaining trust and acceptance. The Empathy Map below has, apart from my John-motto of course, helped me in changing my perspective.</span></p><h2>The Empathy Map</h2><p>The Empathy Map is a technique developed by <a title=”Go to the EXPLANE website” href=”http://www.xplane.com/”>XPLANE</a> and presented in the book <a title=”Book: business Model Generation” href=”http://www.amazon.com/Business-Model-Generation-Visionaries-Challengers/dp/0470876417/ref=sr_1_1?s=books&ie=UTF8&qid=1280587028&sr=1-1″>Business Model Generation</a>. It looks like this:</p><p></p><div class=”captionImage leftAlone” style=”width: 600px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600456-empathy-map-for-business-design.png” width=”600″ height=”456″ alt=”” title=””/><p class=”caption”>Empathy map</p></div><p>The Empathy map is most often used to develop imaginary client profiles for customer segments. I used it for the first time in the field of <a title=”Business Model Management” href=”http://www.bizzdesign.com/consultancy/business-model-management/”>business model management</a>. I find it equally powerful for existing individual clients. It is a collaborative tool for teams (workshops) but I use it for myself on the back of a napkin as well. The following is what I do to get inside my client’s head. Please note I adjusted some of the standard questions in the technique to fit my purpose here: </p><p><span style=”font-size: 11px; line-height: 19px;”>1. Tape a big flip over sheet to the wall, in landscape orientation;</span><br/><span style=”font-size: 11px; line-height: 19px;”>2. Draw the head of the manager in the centre – with resembling characteristics for more empathy, and fun – and draw the template around it, with keywords. You can also download the </span><a style=”font-size: 11px; line-height: 19px;” title=”Download the empathy map poster in PDF” href=”http://ebookbrowse.com/empathy-map-poster-pdf-d341627585″>empathy map poster template</a><span style=”font-size: 11px; line-height: 19px;”> </span><span style=”font-size: 11px; line-height: 19px;”>and print a poster;</span><br/><span style=”font-size: 11px; line-height: 19px;”>3. Enter the client’s head and answer the following questions one by one by placing sticky notes on the sheet (in this order).</span></p><div><span style=”font-size: xx-small;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600279-empathy-map-questions-for-business-design.png” alt=”Empathy map questions” title=”Ask these quentions about your client” width=”600″ height=”279″/></span></div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><span style=”font-size: xx-small;”><br/></span></div><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p><span style=”font-size: 11px; line-height: 19px;”>4. Analyse the results above, and answer the following questions:</span></p><p><span style=”font-size: 11px; line-height: 19px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600172-empathy-map-final-questions-for-business-design.png” alt=”Empathy map questions” title=”Final quentions about your client” width=”600″ height=”172″/></span></p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p><span style=”font-size: 11px; line-height: 19px;”><br/></span></p><h2><span style=”font-size: 11px; line-height: 19px;”>The result</span></h2><p>Below I present a case I made anonymous. Let us call my client Kees – team manager, 62 years old, insurance company, 5000+ employees, big change ahead. The result could look like this:</p><p> </p><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600463-Results-empathy-map-Alex-Hendriks2.png” alt=”Empathy map result” title=”This is what is inside your clients head!” width=”600″ height=”463″/><p class=”caption”>If you’re working on buniess change, you should know what is inside your clients head</p></div><p>By entering the head of Kees for about an hour, I changed my perspective and gained some valuable insights for consulting him in the design and change challenges in his project.</p><p>Please share your experiences and ideas on this with me at <a title=”E-mail Alex” href=”mailto:a.hendriks@bizzdesign.com”>a.hendriks@bizzdesign.com</a>, or leave a comment. </p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
I just returned from the OMG/BA Guild Business Architecture Innovation Summit where there was a lot of discussion on the subject of business architecture value. No one had a good answer for either creating a business case or measuring value delivered. This is a challenging topic for a new profession where methods are not standardized, […]
This post is the fifth in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with. […]
Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/ Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here. The questions were: How do you define Business Architecture? What is the role of the business architect? What real world business problems […]
<p><span style=”font-size: 11px; line-height: 19px;”>Let us suppose you work in an organization that needs improvement or change. You are a member of staff whose task is to support this. Perhaps you are a business consultant, a process designer or an architect. Some strategic decisions have been made and you and your colleagues are contributing the best you can. Doing analyses, making designs, supporting members of business management. The last few years your staff team has invested and improved significantly on </span><a style=”font-size: 11px; line-height: 19px;” title=”Training enterprise architecture, training business process management” href=”http://www.bizzdesign.com/training/”>knowledge, methods</a><span style=”font-size: 11px; line-height: 19px;”> and </span><a style=”font-size: 11px; line-height: 19px;” title=”Professional software tools are crucial for effective and efficient design, analyse and improvement of organisations” href=”http://www.bizzdesign.com/tools/”>tooling</a><span style=”font-size: 11px; line-height: 19px;”>. You have already been working hard on a coherent set of models (architecture, process, business objects?) as a basis for designing the business solutions required.</span><span style=”font-size: 11px; line-height: 19px;”> </span></p><div class=”captionImage left” style=”width: 246px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Business-Design.png” alt=”Business Design” title=”A solid business design is the start of ” width=”246″ height=”205″/><p class=”caption”>Creating a design for your business</p></div><p><span style=”font-size: 11px; line-height: 19px;”>In some cases this is enough for successfully facilitating business change. Indeed getting a grip on change in today’s increasingly complex business reality requires professional methods, tools and knowledge. Obviously, a thought-through business solution is a fundament for many successful business improvements.</span><span style=”font-size: 11px; line-height: 19px;”> </span></p><p>In other cases solid business design work is just not enough. When you come to think of it: <em>why do you still see so many business change projects fail? And why is your serious design function in practice not always taken so seriously? And why is there a number of your good staff colleagues who are not happy or even frustrated with the impact of their work?<span style=”font-size: 11px; line-height: 19px;”> </span></em></p><p><em><span style=”font-size: 11px; line-height: 19px;”> </span></em></p><div class=”captionImage left” style=”width: 210px;”><em><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Solid-business-design.gif.png” alt=”Solid Business Design” title=”Sometimes business design is not enough” width=”210″ height=”140″/><p class=”caption”>Getting grip on business change</p></em></div><p><span style=”font-size: 11px; line-height: 19px;”>If you recognize this and find the questions above relevant, please join me in this series of blogs. I have noticed it is often not a lack of analysis or design capabilities that stands in the way of success. I have also experienced that supporting a business manager is often about everything </span><em style=”font-size: 11px; line-height: 19px;”>but</em><span style=”font-size: 11px; line-height: 19px;”> the content of the business problem. It is about context, perspective, about </span><em style=”font-size: 11px; line-height: 19px;”>how </em><span style=”font-size: 11px; line-height: 19px;”>a solution is developed, soft skills, stakes, ownership etcetera. I personally like to call this phenomena the ‘</span><em style=”font-size: 11px; line-height: 19px;”>content paradox</em><span style=”font-size: 11px; line-height: 19px;”>’. It’s influence on bottom-line results can be huge – and that interest me. These ‘other’, sometimes less-tangible, but everyday aspects might also be of interest to you in becoming more effective. In this blog series I intend to share some of my thoughts and experiences on this. The word cloud below gives a sneak preview of the concepts I expect to touch upon.</span></p><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600386-Blog-cloud-Alex-Hendriks-BiZZdesign2.png” alt=”Word cloud Alex Hendriks” title=”Alex Hendriks will write about these topics in following blogs” width=”600″ height=”386″/><p class=”caption”>Blog word cloud Alex Hendriks</p></div><p>So what is your personal top-3 of answers to my ‘<em>why-questions</em>’ above?</p><p>Please share your ideas on this with me at <a title=”E-mail Alex” href=”mailto:a.hendriks@bizzdesign.com”>a.hendriks@bizzdesign.com</a>, or leave a comment. In my next post I will discuss an innovative technique for staff teams to take on their client’s perspective.</p>
While working with a recent partner, the question came up; “What changes are made to the EA approach if agile methods are required, or otherwise heavily encouraged?” The initial answer at the time was “Not many – we already have an agile approach to EA embedded in our Oracle Enterprise Architecture Development Process (OADP), and our Oracle Enterprise Architecture Framework (OEAF) is independent of project management and project development approaches.”
Our OADP has always been agile and therefore supportive of business and government agility – particularly in the current context of severely constrained budgeting cycles. We firmly believe in a “just enough, just in time” philosophy, with collaborative insight and contribution across teams and leadership, and delivery of EA artifacts or guidance tuned directly to prioritized results. This means strategic, useful and reusable guidance modeled and delivered in a manner that supports both longer-term initiatives and near-term objectives.
EA delivered as an agile approach, however, does require continual line-of-sight traceability back to the IT investment strategy – which in turn is aligned to the business strategy.
In other words, a Sprint Iteration approach might be justified (i.e. using the “Scrum” strategy), from all relevant perspectives, to quickly establish a reusable process and metadata model for a common agency function – like “Document Routing and Approval” (DRA). The output might be required to inform a software solicitation (i.e. to explain the requirements). The output might be to establish a reference model and basic governance (business rules) for identifying and improving process efficiencies around the agency where DRA is occurring.
The actual need for this EA artifact (or “Product”, in Agile terms) may be driven from an unanticipated mandate or regulatory change, and therefore require rapid response. The need may also be limited in scope to only a portion of the agency’s business (i.e. those who actually know they need it).
So, an EA Sprint will work, and deliver what’s needed quickly and effectively to the target audience. The highest return on investment (ROI) in this exercise, however, only exists if actual Enterprise traceability and impact assessment occurs. In other words, an agile EA output with a strategic Enterprise outcome.
Note this is a common misunderstanding for Agile software development; Agile programming and project management may deliver useful, rapid and cost-effective “features” from a Backlog of priorities, but much of the supporting infrastructure, integrations and organizational change isn’t delivered using Agile methods, but must evolve in a more strategic, methodic manner. Preferably with EA guidance.
Here’s what should happen. The common DRA process, metamodel and business rules begin to shape, in a somewhat parochial “requirements-driven” context, heavily leveraging the impacted SMEs for a short period of time. As this occurs, the Enterprise Architect and stakeholders begin mapping and comparing the DRA process design (at appropriately coarse levels of abstraction) to any similar that may exist within the agency, or among agency partners or stakeholders. This may require some additional outreach and communication. The EA may find additional SMEs, risk factors, standards, COTS DRA solution accelerators, overlapping data management projects, etc. – essentially other activities or resources that can be used or might be impacted.
The Enterprise Architect is the Scrum Master!
Strategic oversight and influence is therefore brought to bear on the EA sprint, and by leveraging EA methods, the impacts to the rest of the organization plus any modifications to the focus EA artifact can be addressed – entirely within standard and expected IT Governance. The EA artifact development is a Sprint, but actually leverages our lifecycle methodology – from Business Context through Current and Future States, and then Roadmap (i.e. Transitional Architecture) and Governance. The EA Sprint may actually kick off or modify a more holistic EA maintenance process.
We are therefore avoiding an “agile everything” philosophy, though we’re delivering agile results. We contribute over-arching guidance and process for both the DRA project and the organization as a whole, to make sure that all projects underway are still aligned to meet the needs of the business and IT investment constraints.
This is essentially what we believe in applying our EA process, over time or during more Agile response cycles; always raise and maintain focus on the business strategy and drivers to guide the investment of IT budget into those areas that affect the business most – or that are the most immediate priority, such as described above.
Thanks to Oracle Public Sector Enterprise Architect Ted McLaughlan for contributing to this article!
While working with a recent partner, the question came up; “What changes are made to the EA approach if agile methods are required, or otherwise heavily encouraged?” The initial answer at the time was “Not many – we already have an agile approach to EA embedded in our Oracle Enterprise Architecture Development Process (OADP), and our Oracle Enterprise Architecture Framework (OEAF) is independent of project management and project development approaches.”
Our OADP has always been agile and therefore supportive of business and government agility – particularly in the current context of severely constrained budgeting cycles. We firmly believe in a “just enough, just in time” philosophy, with collaborative insight and contribution across teams and leadership, and delivery of EA artifacts or guidance tuned directly to prioritized results. This means strategic, useful and reusable guidance modeled and delivered in a manner that supports both longer-term initiatives and near-term objectives.
EA delivered as an agile approach, however, does require continual line-of-sight traceability back to the IT investment strategy – which in turn is aligned to the business strategy.
In other words, a Sprint Iteration approach might be justified (i.e. using the “Scrum” strategy), from all relevant perspectives, to quickly establish a reusable process and metadata model for a common agency function – like “Document Routing and Approval” (DRA). The output might be required to inform a software solicitation (i.e. to explain the requirements). The output might be to establish a reference model and basic governance (business rules) for identifying and improving process efficiencies around the agency where DRA is occurring.
The actual need for this EA artifact (or “Product”, in Agile terms) may be driven from an unanticipated mandate or regulatory change, and therefore require rapid response. The need may also be limited in scope to only a portion of the agency’s business (i.e. those who actually know they need it).
So, an EA Sprint will work, and deliver what’s needed quickly and effectively to the target audience. The highest return on investment (ROI) in this exercise, however, only exists if actual Enterprise traceability and impact assessment occurs. In other words, an agile EA output with a strategic Enterprise outcome.
Note this is a common misunderstanding for Agile software development; Agile programming and project management may deliver useful, rapid and cost-effective “features” from a Backlog of priorities, but much of the supporting infrastructure, integrations and organizational change isn’t delivered using Agile methods, but must evolve in a more strategic, methodic manner. Preferably with EA guidance.
Here’s what should happen. The common DRA process, metamodel and business rules begin to shape, in a somewhat parochial “requirements-driven” context, heavily leveraging the impacted SMEs for a short period of time. As this occurs, the Enterprise Architect and stakeholders begin mapping and comparing the DRA process design (at appropriately coarse levels of abstraction) to any similar that may exist within the agency, or among agency partners or stakeholders. This may require some additional outreach and communication. The EA may find additional SMEs, risk factors, standards, COTS DRA solution accelerators, overlapping data management projects, etc. – essentially other activities or resources that can be used or might be impacted.
The Enterprise Architect is the Scrum Master!
Strategic oversight and influence is therefore brought to bear on the EA sprint, and by leveraging EA methods, the impacts to the rest of the organization plus any modifications to the focus EA artifact can be addressed – entirely within standard and expected IT Governance. The EA artifact development is a Sprint, but actually leverages our lifecycle methodology – from Business Context through Current and Future States, and then Roadmap (i.e. Transitional Architecture) and Governance. The EA Sprint may actually kick off or modify a more holistic EA maintenance process.
We are therefore avoiding an “agile everything” philosophy, though we’re delivering agile results. We contribute over-arching guidance and process for both the DRA project and the organization as a whole, to make sure that all projects underway are still aligned to meet the needs of the business and IT investment constraints.
This is essentially what we believe in applying our EA process, over time or during more Agile response cycles; always raise and maintain focus on the business strategy and drivers to guide the investment of IT budget into those areas that affect the business most – or that are the most immediate priority, such as described above.
Thanks to Oracle Public Sector Enterprise Architect Ted McLaughlan for contributing to this article!
What is business-architecture? What is its relationship with enterprise-architecture? And what is the business-value of either, or both? The Open Group ran a very useful ‘TweetJam’ – a ‘twitter-conversation – on these themes yesterday, using the hashtag #ogChat. I pulled…
An agile approach to Enterprise Architecture is entirely possible within the formal Oracle Enterprise Architecture Framework – and is essential for business and mission agility within tough and constrained budget contexts.
While working with a recent partner, the question came up; “What changes are made to the EA approach if agile methods are required, or otherwise heavily encouraged?” The initial answer at the time was “Not many – we already have an agile approach to EA embedded in our Oracle Enterprise Architecture Development Process (OADP), and our Oracle Enterprise Architecture Framework (OEAF) is independent of project management and project development approaches.”
Our OADP has always been agile and therefore supportive of business and government agility – particularly in the current context of severely constrained budgeting cycles. We firmly believe in a “just enough, just in time” philosophy, with collaborative insight and contribution across teams and leadership, and delivery of EA artifacts or guidance tuned directly to prioritized results. This means strategic, useful and reusable guidance modeled and delivered in a manner that supports both longer-term initiatives and near-term objectives.
EA delivered as an agile approach, however, does require continual line-of-sight traceability back to the IT investment strategy – which in turn is aligned to the business strategy.
In other words, a Sprint Iteration approach might be justified (i.e. using the “Scrum” strategy), from all relevant perspectives, to quickly establish a reusable process and metadata model for a common agency function – like “Document Routing and Approval” (DRA). The output might be required to inform a software solicitation (i.e. to explain the requirements). The output might be to establish a reference model and basic governance (business rules) for identifying and improving process efficiencies around the agency where DRA is occurring.
The actual need for this EA artifact (or “Product”, in Agile terms) may be driven from an unanticipated mandate or regulatory change, and therefore require rapid response. The need may also be limited in scope to only a portion of the agency’s business (i.e. those who actually know they need it).
So, an EA Sprint will work, and deliver what’s needed quickly and effectively to the target audience. The highest return on investment (ROI) in this exercise, however, only exists if actual Enterprise traceability and impact assessment occurs. In other words, an agile EA output with a strategic Enterprise outcome.
Note this is a common misunderstanding for Agile software development; Agile programming and project management may deliver useful, rapid and cost-effective “features” from a Backlog of priorities, but much of the supporting infrastructure, integrations and organizational change isn’t delivered using Agile methods, but must evolve in a more strategic, methodic manner. Preferably with EA guidance.
Here’s what should happen. The common DRA process, metamodel and business rules begin to shape, in a somewhat parochial “requirements-driven” context, heavily leveraging the impacted SMEs for a short period of time. As this occurs, the Enterprise Architect and stakeholders begin mapping and comparing the DRA process design (at appropriately coarse levels of abstraction) to any similar that may exist within the agency, or among agency partners or stakeholders. This may require some additional outreach and communication. The EA may find additional SMEs, risk factors, standards, COTS DRA solution accelerators, overlapping data management projects, etc. – essentially other activities or resources that can be used or might be impacted.
The Enterprise Architect is the Scrum Master!
Strategic oversight and influence is therefore brought to bear on the EA sprint, and by leveraging EA methods, the impacts to the rest of the organization plus any modifications to the focus EA artifact can be addressed – entirely within standard and expected IT Governance. The EA artifact development is a Sprint, but actually leverages our lifecycle methodology – from Business Context through Current and Future States, and then Roadmap (i.e. Transitional Architecture) and Governance. The EA Sprint may actually kick off or modify a more holistic EA maintenance process.
We are therefore avoiding an “agile everything” philosophy, though we’re delivering agile results. We contribute over-arching guidance and process for both the DRA project and the organization as a whole, to make sure that all projects underway are still aligned to meet the needs of the business and IT investment constraints.
This is essentially what we believe in applying our EA process, over time or during more Agile response cycles; always raise and maintain focus on the business strategy and drivers to guide the investment of IT budget into those areas that affect the business most – or that are the most immediate priority, such as described above.
Thanks to Oracle Public Sector Enterprise Architect Director Bryan Miller for contributing to this article!
Last week I absolutely astounded having read a project report for a follow on Enterprise Architecture engagement that a former colleague had undertaken after I had previously set up the Enterprise Framework and the strategic direction for engagement wi…