tag:blogger.com,1999:blog-23402499.comments2019-09-27T19:10:17.415+00:00Services FabricNigel Greenhttp://www.blogger.com/profile/00426482151464159257noreply@blogger.comBlogger67125tag:blogger.com,1999:blog-23402499.post-71447244082523799922011-02-10T17:59:46.540+00:002011-02-10T17:59:46.540+00:00This post is awesome!
You have effectively compar...This post is awesome!<br /><br />You have effectively compared Project Management to Taoism and it gives us some good deal of learning, such as communication.<br /><br />Great work!Nathaniel @ project management coursehttp://www.pmtrainingonline.com/site/1648622/product/proj_52_a00_bs_enusnoreply@blogger.comtag:blogger.com,1999:blog-23402499.post-80254262005492695612010-09-27T09:55:23.032+00:002010-09-27T09:55:23.032+00:00Nigel, I approach the EA concept from the value ne...Nigel, I approach the EA concept from the value network perspective that you mention in this post. <br /><br />It is, indeed, important that the EA movement reflects deeply on the outcomes of its contribution to Government IT success in the UK. There is growing realisation that current UK Govt. procurement policy, influenced by EA, needs a radical review. <br /><br />Your contribution, here, is a most welcome start, even if it only opens up that glimmer of understanding that it is people ultimately that drive performance, despite the systems and formal processes, underpinned by IT, that operate in parallel with the informal networks that are undrpinned by trust.<br /><br />Following our meeting with Sally Bean in May 2009 I mapped out a rudimentary set of connections between the value network approach (VNA) ( see open respource site at www.openvna.com ) and the EA VPEC-T <br /><br />You can find it in a Google doc spreadsheet here .... http://tinyurl.com/2468ujs<br />Maybe, better late than never!<br /><br />The last row, "behaviour," in the spreadsheet, is not strictly a classic VNA factor, but one that is implicilty connected to it and which appears in the original VNA object model. Behaviour in this context is principally about how people behave / act in the roles they play and how they develop relationships. <br /><br />In the latter, we can see the link to the VPEC-T Trust. Accordingly, it is quite wrong in my view to refer to "relationships" between Roles. <br /><br />Admittedly, we do refer to patterns of relationships when examining organisational configurations, but the heart / soul is missing... the essence of human interaction. A "role", in UK English, is possibly best viewed as a script that real people follow as they participate and contribute to the activities that transfer, enhance, create, co-create value to deliverables, both tangible and intangible, formal and informal within the whole... and Trust is key in this.<br /><br />VPEC-T resonates well with VNA and I look forward to the results of your continuing discoveries. <br /><br />Best wishes, DavidDavid Meggitthttp://www.meggittbird.netnoreply@blogger.comtag:blogger.com,1999:blog-23402499.post-18765891750693814392009-10-02T14:32:15.380+00:002009-10-02T14:32:15.380+00:00Just to elaborate a little on the 'sky hook...Just to elaborate a little on the 'sky hook' idea. The problem is what do we mean by the events? What do we mean by the content? The information systems themselves have no concept of meaning - in my view they mechanically construct content out of events. Therefore, the problem is what do we mean by the events (the meaning of the content is given by the meaning of the events). It is not a weakness of VPEC-T that it takes the meaning of the events as a given, as that it precisely the strength of events as compared to say, processes. In order for the IS to make sense to the people using it, those people broadly have to agree what they mean by the events and this agreement is 'a priori'. If I submit a claim to to an insurance company, we both have to have an a priori idea of what is meant by 'first notice of loss' even it neither of us use that term.John Schlesingerhttps://www.blogger.com/profile/02564163777644343980noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-69272860760426821512009-06-24T08:11:03.402+00:002009-06-24T08:11:03.402+00:00Ah yes, Nigel -- those were fun times!! Hong Kong ...Ah yes, Nigel -- those were fun times!! Hong Kong in '94 or so? Seems you've come a long way since the early mind-mapping on your lap-top (and the back of beer mats) in the pub beneath the hotel.<br /><br />Jack Armstrong<br />ex-DHL SystemsJackhttps://www.blogger.com/profile/12446572224399751946noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-4599359599480130212009-06-14T07:28:17.693+00:002009-06-14T07:28:17.693+00:00John, thanks for the comment and yes, 'common ...John, thanks for the comment and yes, 'common sense' often seems less *common* in EA. We had a similar discussion here earlier: <br /><a href="http://bit.ly/4tmBE" rel="nofollow">http://bit.ly/4tmBE</a><br><br />NigelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-23402499.post-47021133412308628552009-06-14T03:11:45.042+00:002009-06-14T03:11:45.042+00:00Thoughtful posting. I teach the Architecting the E...Thoughtful posting. I teach the Architecting the Enterprise TOGAF 9 cert course - the thing is truly a tome! I'm constantly working to counter what you call the 'industrialization' of EA. Unless it's common sense and can be presented in a form that business stakeholders can understand, EA won't accomplish anything.John Polgreenhttp://polgreenassociates.comnoreply@blogger.comtag:blogger.com,1999:blog-23402499.post-4017819093727670732009-05-07T16:38:00.000+00:002009-05-07T16:38:00.000+00:00I find there are two types of Enterprise Architect...I find there are two types of Enterprise Architect. Those who approach the problem from the front end of the project lifcycle, and those who approach it from the mid-point. <br /><br />If your route to EA was mostly through the Requirements Analysis, Process Modeller, Data Modeller route it should be no surprise you are more comfy with the concepts of Why? than those of How?<br /><br />When talking to people who phone looking for an EA I always start by asking what they mean and stressing that I am a Front-end EA not a Back-End one. Opportunities for puns abound.....Stephen Timbersnoreply@blogger.comtag:blogger.com,1999:blog-23402499.post-72839809806250080192009-03-25T01:28:00.000+00:002009-03-25T01:28:00.000+00:00I've tried to reply to this one several times. Eac...I've tried to reply to this one several times. Each time I have read my response and realized it isn't right/good/worthy. That indicates to me that there is a lot going on with granularity.<BR/><BR/>If I look inside a service, I may well see very fine-grained objects and behaviors. Why? Because, at least for me, it seemed natural to write them that way. Organizing principle, not reusability being the big driver.<BR/><BR/>But then it gets hard. What level of granularity should a complete service (and associated operations) expose? Are all the operations on a service at the same granularity? At least the second question is that they probably aren't. But I don't have a proof either way.<BR/><BR/>As a thinking model, let's imagine a calculation engine service. It isn't a calculator because it has no visual components.<BR/><BR/>The first operation I need is plus (I want to be able to add a pair of numbers together). So, I could make a plus operation on the service, implement it appropriately and all would be well.<BR/><BR/>Then someone announces the need for minus. Minus is tricky, the sequence of operands is important (a-b) != (b-a) - it is not commutative. So maybe I should name the parameters to make sure.<BR/><BR/>We keep adding operations to this calculation engine. Eventually someone adhering to DRY practice will suggest that we should have just one operation - calculate. The first parameter should be the function to be formed, the second parameter the first operand, etc.<BR/><BR/>So now we have a much coarser grained service (albeit a trivial one). Which is better (and why?)<BR/><BR/>I hazard some advantages to each.<BR/><BR/>Separately named functions enable to name my operands properly so I won't mix them up by putting them in the wrong sequence. That seems to be a little less brittle.<BR/><BR/>Separately named functions allow me to handle specific errors (e.g. division by zero) with a great degree of specificity. Again, less brittle.<BR/><BR/>The service looks like what a casual user might expect. The user can see the shape of the business in the solution. This adds credibility. It doesn't look like some clever-dick architect has abstracted it so much that it is incomprehensible.<BR/><BR/>Now looking at the general case. It is easy to add new capabilities. The interface doesn't change at all, but the implementation does. So unaffected clients aren't impacted. That feels like goodness.<BR/><BR/>You have some standardized error handling available - checking the types of the arguments, etc.<BR/><BR/>You are maintaining and documenting one interface, not many.<BR/><BR/>So what is the correct level of granularity. The jury is out - at least based on the cases I have discussed here. There may be some discriminators which help us to decide. But what are they?<BR/><BR/>Answering that last question will give us some insights into how to think about granularityChris Birdhttps://www.blogger.com/profile/13436436994311245922noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-9328940994474295752009-03-23T10:12:00.000+00:002009-03-23T10:12:00.000+00:00Great post Nigel. There is often talk about the im...Great post Nigel. <BR/><BR/>There is often talk about the importance of 'soft' skills, but usually in a nebulous sense. This thinking flips things around to place communication at the heart of matters, which, as you say, it surely is.Carl Batehttps://www.blogger.com/profile/09763556634029250557noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-1463834140604606982009-03-18T17:23:00.000+00:002009-03-18T17:23:00.000+00:00I'm afraid I think starting from a 'execute a proc...I'm afraid I think starting from a 'execute a process' PoV misses the point of this post. Of course, as you know, I'm not anti-process per se (that's like being anti-air!) - my point is that we need to recognise the variety of processes that exist within an enterprise. Some will never be 'executed' but all might need to be visible, for example. I see Events as both bread-crumb trail and actionable DNA of a process. <BR/><BR/>It's good to see you are as feisty as ever Howard.<BR/>n.Nigel Greenhttps://www.blogger.com/profile/00426482151464159257noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-76538949957223665892009-03-18T16:16:00.000+00:002009-03-18T16:16:00.000+00:00I think that poking at processes in this way is so...I think that poking at processes in this way is somewhat missing the point. If you want a process to execute it needs to be defined. But even here, process systems these days tend to support rich semantics for asynchronous interactions. It is quite feasible to model the kind of processes you are speaking of, and still execute them in computer systems or simulation tools.Howard Smithhttps://www.blogger.com/profile/15568310245826725480noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-23269389151732477752009-03-17T13:44:00.000+00:002009-03-17T13:44:00.000+00:00Interesting, indeed. The value I get from Twitter ...Interesting, indeed. The value I get from Twitter is also about tapping into interesting ideas. Through Twitter, a lot of interesting links are shared, and it gives me the opportunity to stay tuned to some old friends. Anyway, I think it is a valuable tool. And for Argey, check this link. http://tinyurl.com/cdnvw3Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23402499.post-16149373230552105152009-03-03T09:38:00.000+00:002009-03-03T09:38:00.000+00:00Point taken. I did find the C-MAP very instructive...Point taken. I did find the C-MAP very instructive so I'm glad in this instance that you did publish it. Not many people are as picky as I am, when it comes to dissecting diagrams.Cybersalhttps://www.blogger.com/profile/15258055798612329124noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-101266336263744352009-03-03T08:52:00.000+00:002009-03-03T08:52:00.000+00:00Sally, actually the concept wasn't important (to m...Sally, actually the concept wasn't important (to me) at the time I was creating the c-map. What was important was to capture my train of thought following Richard's question given I already think 'community/network' as a baseline. Perhaps it was a mistake to publish my raw thinking in the c-map? Let's discuss when we meet today.<BR/>n.Nigel Greenhttps://www.blogger.com/profile/00426482151464159257noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-32339228503413066712009-03-03T08:24:00.000+00:002009-03-03T08:24:00.000+00:00Nigel, in reply to your comment above and to clari...Nigel, in reply to your comment above and to clarify mine: I do appreciate that people are very much at the core of the VPEC-T mindset and pervade the diagram. I was making a technical observation on the concept map because I believe that it's a good principle to make important concepts explicit rather than implicit when analysing and diagramming them. <BR/><BR/>Also I tend to start any piece of work with a stakeholder/organisational analysis, myself.Cybersalhttps://www.blogger.com/profile/15258055798612329124noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-76653603545791785312009-03-02T11:49:00.000+00:002009-03-02T11:49:00.000+00:00@karen: Thanks for the comment. I'm a little conce...@karen: Thanks for the comment. I'm a little concerned that you think VPEC-T is a software product or similar. It's a thinking framework so similar to SWOT analysis in its simplest form. There are lots of links to VPEC-T resources on this blog - try following some of the links words and take a look at the Lost In Translation sideshow in the sidebar.<BR/><BR/>Thx<BR/>Nigel<BR/><BR/>P.S. I am expecting VPEC-T based modelling tools to be developed in the future.Nigel Greenhttps://www.blogger.com/profile/00426482151464159257noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-58960464688814597742009-03-02T11:38:00.000+00:002009-03-02T11:38:00.000+00:00The VPEC-T technology is most comprehensive techno...The VPEC-T technology is most comprehensive technology and it is very useful for the people who are aware about this technology but the blog does not contain enough information so new users will not be able to get enough out of it.<BR/><BR/>Karen Walter<BR/><A><BR/>Drug Intervention Colorado</A>Karen Walterhttps://www.blogger.com/profile/11827439122186597568noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-89253982108389045882009-03-02T11:17:00.000+00:002009-03-02T11:17:00.000+00:00@Colin Beveridge: Sorry, I missed it, WRT Simplici...@Colin Beveridge: Sorry, I missed it, WRT Simplicity v Complexity I'm reminded of some recent tweets with Roger Sessions. I don't presume that Complexity is always bad (this is not expressed in the c-map)like Richard Varyard tweeted last night:<BR/>"Complexity itself is not the enemy. We need complexity, just as healthy bodies need friendly bacteria".<BR/><BR/>My point on the c-map was to remind myself that Yak Shaving (often unavoidable) might be usefully examined using VPEC-T - not a main thought hence the dotted lines!<BR/>n.Nigel Greenhttps://www.blogger.com/profile/00426482151464159257noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-63353724350632675722009-03-02T10:58:00.000+00:002009-03-02T10:58:00.000+00:00NigelI also think of quality and value from a Pirs...Nigel<BR/><BR/>I also think of quality and value from a Pirsig perspective, rather than the generally-held "value for money" perspective.<BR/><BR/>But what about complexity and simplicity?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23402499.post-33482798904273785062009-03-02T10:53:00.000+00:002009-03-02T10:53:00.000+00:00@Colin Beveridge: In the broad Pirsig sense, Quali...@Colin Beveridge: In the broad Pirsig sense, Quality and Value are covered by Value (Systems of Value - what do I care about). In a narrow sense, of say 'Value For Money' or 'Quality Of Service' these would be Cross Cutting Concern rows (or row elements). The rows provide 'the reason' for thinking the VPEC-T dimensions.Nigel Greenhttps://www.blogger.com/profile/00426482151464159257noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-10802060936097080522009-03-02T10:45:00.000+00:002009-03-02T10:45:00.000+00:00@cybersal: I must admit I was always thinking 'com...@cybersal: I must admit I was always thinking 'community' as I drew the map. The reason the Use Patterns are highlighted is because they are to be created by communities and used by communities to convey 'meaning' by showing that 'meaning' depends on the context under which you apply VPEC-T. <BR/><BR/>Within the context of VPEC-T itself communities/groups are associated with 'Values' and 'Trust' in the same way individuals are. I don't differentiate between a person or a group in this sense.Nigel Greenhttps://www.blogger.com/profile/00426482151464159257noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-71044686694117856062009-03-02T10:15:00.000+00:002009-03-02T10:15:00.000+00:00an interesting post, thanks Nigel.I just wondered ...an interesting post, thanks Nigel.<BR/><BR/>I just wondered where quality and value fit into the framework and I am not so sure that simplicity is necessarily an antonym for complexity.<BR/><BR/>In some circumstances complexity might simply [sic] be a function of aggregated simplicity.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23402499.post-8826380104630699092009-03-02T09:53:00.000+00:002009-03-02T09:53:00.000+00:00Nigel, It's hard to talk about meaning without tal...Nigel, It's hard to talk about meaning without talking about people. I think it's striking that the only people-related concept on your map is the VPEC-T practitioner plus a reference to user-centric approaches. Do you need to add in a 'community' concept - you can have communities that share a practice, share a culture, or share a set of semantics (i.e.meaning).Cybersalhttps://www.blogger.com/profile/15258055798612329124noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-55673084738173786152009-02-21T06:14:00.000+00:002009-02-21T06:14:00.000+00:00Nigel, Just started using TweetDeck which helps, b...Nigel, Just started using TweetDeck which helps, but the problem I have is lack of context. Using search, I find answers to questions without the questions and single-sided conversations that are not monologues.<BR/><BR/>Still feeling may way, as I spend very little time trying. And time is another problem!<BR/><BR/>I'm not having Chris' problem with CPU usage (TweetDeck running at present and is using 1% of CPU).<BR/><BR/>RoyArgeyhttps://www.blogger.com/profile/10160478171380046327noreply@blogger.comtag:blogger.com,1999:blog-23402499.post-45838624691557959522009-02-17T00:03:00.000+00:002009-02-17T00:03:00.000+00:00Really interesting discussion - so many facets of ...Really interesting discussion - so many facets of it to comment on. I agree about needing to be cautious about using the term 'Systems Thinking', because there seem to be many differing perspectives on what systems thinking is (it's not unlike Enterprise Architecture in that respect), in addition to what Nigel has described here. <BR/>Some people equate it with systems dynamics. <BR/>Peter Checkland provides a good description of his 'softer' perspective on it here. He sees it more as an ongoing 'process of enquiry' http://www.open2.net/systems/practice/pet.html<BR/><BR/>John Seddon also calls his approach for applying Lean thinking to service design, 'Systems Thinking' yet it's quite different from Checkland's.<BR/><BR/>I've just been reading Patrick Hoverstadt's book on the Fractal Organisation which is basically 'Viable systems modelling for managers' and which tries very hard to use language that is meaningful to mere mortals. I can't really judge whether he's been successful because I had already swallowed the Systems Thinking 'red pill' before I'd read it. See the review on Amazon http://www.amazon.co.uk/review/R8J3GRHQSBOQECybersalhttps://www.blogger.com/profile/15258055798612329124noreply@blogger.com