ArchiMate from a data modelling perspective

<p><em><span style=”font-size: 11px; line-height: 19px;”>After my webinar on “building a data management capability with <a href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/togaf/”>TOGAF</a> and <a href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/”>ArchiMate</a>” I received several E-mails with interesting questions and useful suggestions. In one of those conversations we touched upon an issue that I stumble across in practice a lot: how to effectively use the classic ‘conceptual / logical / physical’ dichotomy when modelling with ArchiMate. </span><span style=”font-size: 11px; line-height: 19px;”>After some E-mails back and forth, I found myself writing a rather long note which might be useful for a broader audience. I’ve included it below. I left out a few sentences here and there due to privacy considerations.  If you have any related thoughts or suggestions, please drop me a note or leave a comment. </span></em></p><p><span style=”font-size: 11px; line-height: 19px;”>If you like the work of Halpin, then I can recommend Kent as well. His classic book on “<a href=”http://www.amazon.com/Data-Reality-Perspective-Perceiving-Information/dp/1935504215″>Data and reality</a>” is now available as e-book. Good read with some thoughts that are still more than relevant. Let’s dive in […]. There are 2 aspects that are relevant in my opinion: (1) the dichotomy of architecture and design, and (2) the conceptual / logical / physical distinction.</span></p><p><span style=”font-size: 11px; line-height: 19px;”>ad 1: dichotomy of architecture and design</span></p><p>For some reason this remains tricky for many practitioners. Constantly confusing the two “levels”. Of course we can argue that <a href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/togaf/”>Enterprise Architecture</a> is also a form of design… but that’s not the point. Following the generally accepted definitions, architecture deals with the fundamental organisation of a system as well as the principles guiding design and evolution. It’s high level, about coherence, and about how “things” in the enterprise are put together. The actual details of how things are organized in reality are more “Design” or “implementation”. For a previous Webinar I made the following illustration:</p><p><img alt=”Identifying solutions in ArchiMate” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/capability-architecture-solution-model.png” style=”width: 300px; height: 239px;” title=”ArchiMate can be used for identifying solutions (i.e. the SBB’s in TOGAF)”/></p><p><span style=”font-size: 11px; line-height: 19px;”>ArchiMate is very usable for architecture models. For identifying solutions (i.e. the SBB’s in TOGAF), ArchiMate is very usable too. For fleshing out the details, we need more detailed solution models and tend to use different notations, such as UML, BPMN, SBVR and so on. </span></p><p>ad b. conceptual / logical / physical</p><p>Unfortunately here too we see many different interpretations. You’d think we have figured it out by now. Here are two interpretations that are used a lot:</p><p><img alt=”Conceptual, logical and physical models” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/conceptual-logical-physical-model-data.png” style=”width: 379px; height: 273px;” title=”A conceptual model captures the business scope of the business solution, and the physical the technical solution.”/></p><p>TOGAF seems to follow the interpretation close to Capgemini’s IAF where conceptual is about “what”, logical is about “how” and physical is about “with what”. In that case, conceptual/logical appears to map on the architecture level, whereas physical seems to map on the design/ implementation level. All three are somewhat in line but in practice we still see people mix-and-match between abstraction levels.</p><p>My personal view is that we should pay close attention to the “level” (architecture / design) and “abstraction” (conceptual / logical / physical) that we’re working on. Don’t mix them. Also, I tend to merge the conceptual/logical levels at least for my ArchiMate models. That makes it easier to understand for many stakeholders in practice. Consider this simple example to see how it can work:</p><p><img alt=”You can merge the conceptual and logical levels in ArchiMate to make it easier to understand for many stakeholders” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/data-modelling-business-process.png” style=”width: 414px; height: 347px;” title=”A merged version of the conceptual, logica land physical models”/></p><p> </p><p>If you follow the strict definitions then you could argue that:</p><ul><li>conceptual: what is needed is the two application services s1 and s2</li> <li>logical: how  we go about realizing it? In this case (due to some principles), apparently we chose for a solution with a single application component. For example “the ERP package”</li> <li>physical: with what is not in this model. There we have to look for physical counterparts of this ERP package. For example “SAP R/3″</li></ul><p>The same line of reasoning can be repeated between the application layer and the technology layer. Great, but what about the information/data world? <span style=”font-size: 11px; line-height: 19px;”>I really like the way ArchiMate decided to not introduce a separate layer for information/ data […] I want to be able to talk about “what information is needed in the context of some business process or organisational role”, or about “which data sits in what system” or “how did we organize information storage in in the infrastructure”. Of course the data dissemination (one of the viewpoints in TOGAF) is part of that.</span></p><p>While I agree that the definition of business object / data object / artefact / representation can be improved further, the intention behind them does work in practice. Let’s start with the conceptual/ logical level (incomplete, but it gives an idea):</p><p><img alt=”Application and technology layer in ArchiMate” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/ArchiMate-conceptual-logical-level.png” style=”width: 500px; height: 399px;” title=”What information is needed in the context of some business process or organisational role”/></p><p>Here we see the following:</p><ul><li>In some process we need a bit of information (bo1). With bo1 (which is what I called an Entity in my webinar) we can represent attributes and all sorts of metadata. </li> <li>In order to get to this information, we need two data objects. That is, it appears that there are two data objects, both managed by the same system, which together realize the information that is needed for bo1. Remember that this is the architecture level. If we really want to dive into mappings between definitions, attributes, fields and so on then (in my opinion) we cross over into the realm of design. I’d be much happier using my favourite ORM2 or ERD tool for that!</li> <li>We also see that the application component needs (at least) two bits of infrastructure in order to function. Data storage and rule execution. Note that I haven’t specified what type of storage this will be. That’s an implementation choice that can be made later. Are we going for relational? or xml db? or flat file? At this point I don’t care!</li></ul><p>Diving into the solution would be something along the lines of:</p><p><img alt=”SAP R/3 component” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130514_ArchiMate-from-a-data-modelling-perspective/ArchiMate-solution.png” style=”width: 500px; height: 275px;” title=”deployment of the executables that make up the SAP R/3 component”/></p><p> </p><p>Here we see the actual deployment of the executables that make up the SAP R/3 component (the two top artefacts) on the system software in the infrastructure. We also see how the artefacts are accessed by this system software. Note the dual use of the artefact concept: on the one hand it is used as the manifestation of data in the infrastructure, on the other it is used as an executable. Not ideal, but it is what it is…</p><p>One thing that we still have to do is linking our conceptual / logical models to the physical models. There is no built-in mechanism in ArchiMate to handle this (the specialisation relation comes close but doesn’t do what you want it to do). Most tools these days (BiZZdesign Architect included) use the idea of “dependency relations” to create links across models.</p><p>I think that it is high time for some best practices on how to deal with these issues. I also agree that a lot can be learned from the past. It’s up to us to make that happen!</p>

Categories Uncategorized

Three Decision Model Predictions and The Decision Modeler

<p><a href=”http://www.kpiusa.com/index.php/The-Decision-Model/the-decision-model.html”>The Decision Model</a> (TDM) is new and rapidly growing methodology and framework for modelling the business logic (business rules) behind business decisions, using a powerful graphical notation, that is easy for both business and IT to understand and implement.</p><p><span style=”font-size: 11px; line-height: 19px;”><img alt=”” class=”right” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130506_Three-Decision-Model-Predictions-and-The-Decision-Modele/Decision-Modeler-Method-KPI.png” style=”width: 120px; height: 124px; float: right;” title=””/>The Decision Model was co-invented by </span><a href=”http://www.linkedin.com/in/larrygoldbergkpi” style=”font-size: 11px; line-height: 19px;”>Larry Goldberg</a><span style=”font-size: 11px; line-height: 19px;”> and </span><a href=”http://www.linkedin.com/pub/barb-von-halle/1/7ab/130″ style=”font-size: 11px; line-height: 19px;”>Barbara von Halle</a><span style=”font-size: 11px; line-height: 19px;”>, who are the co-authors of the seminal book </span><a href=”http://www.amazon.com/Decision-Model-Framework-Technology-Management/dp/1420082817″ style=”font-size: 11px; line-height: 19px;”>“The Decision Model: A Business Logic Framework Linking Business and Technology“.</a> <span style=”font-size: 11px; line-height: 19px;”>In early January 2012, I made <a href=”http://www.azintablog.com/2012/01/08/three-predictions-for-the-decision-model-in-2012/”>three predictions</a> about the urgent need for a low cost software tool that would support the modelling of TDM models, and, that this tool would be available by the end of 2012.</span></p><p>It is now 5 months after my original predictions were expected to be fulfilled and this blog post briefly outline the three original TDM predictions and compare them with the functionality of the new TDM tool, The Decision Modeler, which will be launched in early June 2013 by <a href=”http://www.bizzdesign.com”>BiZZdesign</a></p><h2><span style=”font-size: 11px; line-height: 19px;”><img alt=”” class=”right” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130506_Three-Decision-Model-Predictions-and-The-Decision-Modele/the-Decision-Modeler-logo.jpg” style=”width: 100px; height: 120px; float: right;” title=””/>My Original Decision Model Prediction 1</span></h2><p>By the end of 2012 a low cost entry-level TDM modelling tool will exist that will enable modellers to create and validate that their TDM models comply with the TDM 15 principles. There is currently only one tool that has this capability and that is the <a href=”http://www.sapiensdecision.com/”>heavy-weight Sapiens DECISION tool.</a>  DECISION is designed for enterprise TDM modelling, life-cycle management and governance.</p><p>My reasons for an entry-level low cost TDM modelling tool are:</p><ul><li>There are a large number of small to medium size companies who in the coming months and years would like to use TDM but who will not be able to afford heavy-weight tools such as Sapiens DECISION. Using Excel and Visio for TDM modelling is better than nothing but a modelling tool with proper validation would be much better.</li> <li>Many departments in many large companies may still like to experiment with TDM using a low-cost entry tool to get started and after the success of an initial TDM project move up to governance products such as Sapiens DECISION.</li> <li>Having a low-cost or open source TDM modelling tool will empower many thousands to experiment on their own and drive the bottom-up adoption of TDM within organisations of all sizes.</li></ul><h2><span style=”font-size: 11px; line-height: 19px;”>My Original Decision Model Prediction 2</span></h2><p>By the end of 2012 a low cost TDM model translator will exist that will be able to automatically convert high-level graphical TDM models into actual “business rules code” for a number of business rules engines.</p><p><em>This tool will enhance the productivity of business rules programmers and ensure that Decision Models are converted without error into code that can execute within different rule engines.</em></p><h2><span style=”font-size: 11px; line-height: 19px;”>My Original Decision Model Prediction 3</span></h2><p>From my perspective Business Decision Management = BPMN + TDM. It is therefore my prediction is that by end of 2012 that a low-cost entry tool will exist that will enable business analysts and TDM modellers to model TDM and BPMN process models in an integrated modelling environment. <span style=”font-size: 11px; line-height: 19px;”>Let’s not forget that actions required to be executed on completion of a TDM decision should be executed within a BPMN process task. See The Decision Model Book by Barbara von Halle and Larry Goldberg. Also for more information on the integration of TDM with BPMN process models see the <a href=”http://brsilver.com/integrating-process-and-rules-part-2/”>BPMN guru Bruce Silver’s blog post</a></span></p><h2><span style=”font-size: 11px; line-height: 19px;”>The Three Predictions and The Decision Modeler</span></h2><p>At the time that I made these prediction I was not aware that BiZZdesign was about to embark on developing a TDM tool.  It was only until the autumn of 2012 that I became aware of BiZZdesign TDM plans and finally an alpha version of the tool was available by end of 2012.</p><p>So how does BizzDesign’s The Decision Modeler compare with the three TDM predictions?</p><ul><li><strong>TDM Prediction 1 and The Decision Modeler </strong>– BiZZdesign’s The Decision Modeler is priced at around $5,000 for a single user licence and later a lower priced SaaS/Cloud version is planned. The Decision Modeler current checks for some of the 15 principles, including the structural principles and some other checks. In forthcoming releases the software will validate for all the 15 principles. I can therefore confirm that The Decision Modeler meets TDM Prediction 1.</li> <li><strong>TDM Prediction 2 and The Decision Modeler</strong> – BiZZdesign has the ability to export TDM models into Excel format that enables TDM models to execute on the <a href=”http://openrules.com”>OpenRules open source business rules platform</a>.  The ability to export to other business rules platforms such as Drools and ILOG are on the roadmap. I can therefore confirm that The Decision Modeler meets TDM prediction 2.</li> <li><strong>TDM Prediction 3 and The Decision Modeler</strong> –The Decision Modeler has excellent integration with process modelling tools. Both BPMN 2.0 standard and proprietary Amber process modelling languages are fully supported and integrated with The Decision Modeler into an integrated modelling environment. I am therefore very pleased to say that the Decision Modeler fully implements TDM Prediction 3.</li></ul><p><span style=”font-size: 11px; line-height: 19px;”>The Decision Modeler enables a TDM modeller view all the process models that are using a specified TDM model. From a process model, one can click on a business decision task and automatically view the associated TDM model. No other TDM tool has this tight execution with process models, out of the box, as does The Decision Modeler.</span></p><p>I can therefore confirm that The Decision Modeller meets all the three TDM Predictions.</p><p>Given that TDM is rapidly revolutionising enterprise business decision management, by enabling the business to re-gain control of the business decisions that business managers are responsible for managing, I believe that the Decision Modeler will have a significant impact by reducing the costs of engaging with TDM.</p><h2>Future Predictions for Decision Modeler</h2><p>It is my view that the Decision Modeler, including the integration of TDM with other BiZZdesign modelling tools and languages will rapidly grow from strength to strength in subsequent releases. It is my prediction that BiZZdesign will become the de facto modelling tool for doing TDM modelling within the enterprise.</p><p>The second post in the 3-part series will look at how BiZZdesign has integrated TDM with its other modelling tools and languages and some of the implications of this integration for the business and IT.</p><p>In the olden days, thousands of years ago, prophets who made predictions that did not materialise were either ignored or more often stoned to death as false prophets.  So my thanks BiZZdesign for developing its TDM product, The Decision Modeler, just in time!</p><p>By <a href=”http://suleiman.shehu@azinta.com”>Suleiman Shehu</a></p><p><span style=”font-size: 11px; line-height: 19px;”>Suleiman Shehu is the CEO, of Dublin based <a href=”http://www.azinta.com”>Azinta Systems Ltd</a>. Azinta Systems is a business transformation, business integration and consultancy company. Azinta is a KPI The Decision Model consulting partner for the Europe, Middle-East and Africa (EMEA).</span></p><p><span style=”font-size: 11px; line-height: 19px;”>Azinta has recently signed a strategic business partnership with BiZZdesign for EMEA region and Azinta will be providing TDM consulting and TDM methodology training services for those looking to start using TDM with the Decision Modeler.</span></p><p><span style=”font-size: 11px; line-height: 19px;”>Suleiman can be contacted at Suleiman,shehu@azinta.com. The <a href=”http://www.azintablog.com/2012/01/08/three-predictions-for-the-decision-model-in-2012/”>original article on the three TDM predictions can be viewed.</a></span></p>

Categories Uncategorized

Business Architecture and Related Domains

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…

Categories Uncategorized

From Business Design to Business Change (#2) – Be John Malkovich!

<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&amp;ie=UTF8&amp;qid=1280587028&amp;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>

The Project Business Sprintlines

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. […]

Business Architecture

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 […]

From Business Design to Business Change (#1) – The Content Paradox

<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>

Categories Uncategorized

An Agile Enterprise Architecture (EA) Delivers Critical Business and Mission Agility

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!

An Agile Enterprise Architecture (EA) Delivers Critical Business and Mission Agility

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!