tag:blogger.com,1999:blog-6106782.post4314004638452737464..comments2024-03-27T10:47:33.255+00:00Comments on Architecture, Data and Intelligence: Six Views of Business ArchitectureRichard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-6106782.post-81281096539222279442012-06-08T13:13:31.743+01:002012-06-08T13:13:31.743+01:00Alex
I think the critical thing about services is...Alex<br /><br />I think the critical thing about services is the decoupling between the external view (Relationships, Interfaces) and the internal view (Capabilities, Components). See my post on <a href="http://rvsoapbox.blogspot.co.uk/2010/06/ecosystem-soa-2.html" rel="nofollow">Ecosystem SOA</a>. There is then a further decoupling between the external view and the customer experience, which is covered by the Motivation view. <br /><br />What about Location? As a business architect, I'm much more interested in organizational boundaries than geographical distance. Obviously there are some implementation issues and risks associated with location, especially when a capability is situated in a single place, or governed under a single regulatory regime, but I don't think these need to be part of the business architecture. As far as I'm concerned, location is just an attribute, like currency or timezone.Richard Veryardhttps://www.blogger.com/profile/04499123397533975655noreply@blogger.comtag:blogger.com,1999:blog-6106782.post-23986921238213563692012-06-08T03:56:31.113+01:002012-06-08T03:56:31.113+01:00Richard,
Thanks for another excellent post. I cre...Richard,<br /><br />Thanks for another excellent post. I created a similar 6 view model a couple of years ago and have found it very useful for a variety of uses most notably benefits planning, portfolio management & alignment to motivation.<br /><br />I personally use a separate layer for all of data, information and knowledge and then map them but I can see why and how you have included the knowledge view.<br /><br />So the view that I have instead is a "business services" view which essentially allows for thinking through the lens of customer experience. I don't see where you are accounting for that in your views / model. Would you be kind enough to talk me through how you account for that please? Is it in the relationships view?<br /><br />Also location. Location can be important for such things as business continuity planning and time zone planning, etc. Where do you account for location please?<br /><br />Thanks again for the great postAlex Matthews (@remembermytweet)http://www.enterprise-advocate.comnoreply@blogger.comtag:blogger.com,1999:blog-6106782.post-66295222792414763152012-06-08T02:07:16.347+01:002012-06-08T02:07:16.347+01:00What exactly is an architecture domain anyway? Wik...What exactly is an architecture domain anyway? Wikipedia seems to think it is the same as a view or viewpoint. Or maybe it is a set of stakeholders/concerns.<br /><br />TOGAF tells us that the world can be understood as a series of discrete domains, and then persuades us to worry about the balance or imbalance between these domains. But if we move away from TOGAF territory, I don't see why I need to care very much about this rhetorical imbalance.<br /><br />As for the word "implementation", this implies a separation between design and execution, or between a decision/policy and the following action. But does that entail separate viewpoints for the design and for the execution, or for the decision/policy and for the action?Richard Veryardhttps://www.blogger.com/profile/04499123397533975655noreply@blogger.comtag:blogger.com,1999:blog-6106782.post-7576095605157675672012-06-07T21:08:34.723+01:002012-06-07T21:08:34.723+01:00Richard
I deliberately chose "implementation&...Richard<br />I deliberately chose "implementation" in order to be broader than IT. Poor choice. No matter. My point was that TOGAF manages to define three architectures in just the IT domain and this creates an imbalance, which reflects TOGAF's IT orientation. If we were to have other domains like HR, Legal or any service delivery domain, then at least some of them would merit an architecture. So putting everything you've covered into one single architecture may create a greater imbalance than we already see in TOGAF. <br />Maybe it wouldn't but it struck me as worth thinking about.<br />That aside I'll come back on requisite variety, when I've thought about it some more.Anonymoushttps://www.blogger.com/profile/06162188932704847995noreply@blogger.comtag:blogger.com,1999:blog-6106782.post-12228237886974030792012-06-07T19:40:38.400+01:002012-06-07T19:40:38.400+01:00Some great questions from Stuart. Here are some qu...Some great questions from Stuart. Here are some quick answers.<br /><br /><i>Do you foresee a link upwards to stakeholders and their concerns a la ISO 42010 (IEEE1471)? Or are the viewpoints implicitly stakeholder specific?</i><br /><br />I interpret ISO 42010 as mandating many-to-many relationships between stakeholder/concerns and viewpoints.<br /><br /><i>And downwards to model types? I could imagine more than one model being useful for some of the viewpoints.</i><br /><br />Yes, absolutely. For example, within the Business Motivation view, we might have simple BMM models and more sophisticated i* models, as well as both qualitative and quantitative models. <br /><br /><i>I very much like your use of “Business Knowledge View” – gets us away from endless discussions about data vs information. And it’s the knowledge that matters at this level.</i><br /><br />I'm not taking credit for the name, but I agree that we are interested in What-The-Business-Knows (as well as how it knows what it knows).<br /><br /><i>I also strongly agree that strategy exists to realize motivation.</i><br /><br />This seems obvious to me, but it seems not to be obvious to everyone else.<br /><br /><i>I’m hesitant about the idea that the organization can control the level of variety it needs to respond to. I agree that it can influence that by choosing to restrict its interfaces with the outside world but there are always going to be sources of variety it can’t avoid and which it therefore will have to take into account in its capabilities and/or organizational model.</i><br /><br />The word "needs" here is the problem. The organization effectively chooses how much variety to respond to and how much variety to ignore - and it can be staggering how much an organization can ignore things that others think to be important. (There is a link here to the Management View.) These choices may not be consciously debated, but they are implicit in the structure and behaviour of the organization.<br /><br /><i>Lastly, I may have missed something but I have the feeling that your viewpoint set covers everything apart from the implementation side of an enterprise architecture. That makes me slightly concerned about calling it all Business Architecture. It feels dangerously close to the TOGAF treatment of BA as everything that isn’t IT, which an increasing number of us (including friends of TOGAF) are uncomfortable about. I’m sure that’s not your intention but would like to know your take on this.</i><br /><br />What exactly do you mean by "implementation"? The business architecture is implemented in many ways - for example, not only in IT systems but also in physical processes and bureaucracy. TOGAF may not have implementation domains called HR and Legal (where we would find implementation artefacts such as job descriptions and bonus schemes, as well as legally binding documents such as outsourcing contracts), but there's nothing stopping us defining such domains.Richard Veryardhttps://www.blogger.com/profile/04499123397533975655noreply@blogger.comtag:blogger.com,1999:blog-6106782.post-54273341160619002882012-06-07T17:03:33.153+01:002012-06-07T17:03:33.153+01:00This is superb! Thanks. I have a few questions and...This is superb! Thanks. I have a few questions and comments.<br /><br />Do you foresee a link upwards to stakeholders and their concerns a la ISO 42010 (IEEE1471)? Or are the viewpoints implicitly stakeholder specific?<br />And downwards to model types? I could imagine more than one model being useful for some of the viewpoints.<br />I very much like your use of “Business Knowledge View” – gets us away from endless discussions about data vs information. And it’s the knowledge that matters at this level.<br />I also strongly agree that strategy exists to realize motivation.<br />I’m hesitant about the idea that the organization can control the level of variety it needs to respond to. I agree that it can influence that by choosing to restrict its interfaces with the outside world but there are always going to be sources of variety it can’t avoid and which it therefore will have to take into account in its capabilities and/or organizational model.<br />Lastly, I may have missed something but I have the feeling that your viewpoint set covers everything apart from the implementation side of an enterprise architecture. That makes me slightly concerned about calling it all Business Architecture. It feels dangerously close to the TOGAF treatment of BA as everything that isn’t IT, which an increasing number of us (including friends of TOGAF) are uncomfortable about. I’m sure that’s not your intention but would like to know your take on this.<br /><br />Once again thanks.Anonymoushttps://www.blogger.com/profile/06162188932704847995noreply@blogger.com