tag:blogger.com,1999:blog-66017088268986865112024-02-01T20:17:42.776-08:00Methods and toolShare Information on methodologiesMichael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-6601708826898686511.post-56414415893836123782015-04-27T14:28:00.001-07:002015-08-05T17:18:17.122-07:00Visualising Architectures using data in TrouxThere are many ways of visualising data held in Troux. Troux provides OTB diagram generation -<br />
- using Flash frameworks in the Troux Navigate Portal<br />
- using Troux Architect fat client modelling tool<br />
<br />
Here are some of the features we think people want: <a href="https://docs.google.com/spreadsheets/d/1NPsr4ZiaT89cHyxWETqT4jwwq9GmyuYSQig0RwUp458/pubhtml">Features of Visualisations</a><br />
<br />
There are other ways of visualising data held in Troux: <a href="https://docs.google.com/document/d/1TkNzbm4EUpHe68QwNm9QEpq7cY5e2nz3cM1Qq1hs5OE/pub">SEMPRE Visualisation Framework</a><br />
<br />
Conceptual views <a href="https://docs.google.com/drawings/d/1ysCqHYLBRABGkh7qmLnLoHAYLVsnVZweDJpk8SgUwhM/edit?usp=sharing">Common views producing models, documents, reports</a><br />
<br />Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-55461313064529950972014-02-09T14:32:00.001-08:002018-06-26T16:06:55.618-07:00Round tripping and other IT fairy storiesIT should recognise that round tripping seldom takes places automatically in mature domains. Design are not normally round tripped. If the data passed in is changed those changes are usually dealt with by a specific process i.e.<br />
- a cadastral function defines boundaries and other features of the land may be recorded e.g. trees, streams, walls etc.<br />
- a town plan has a map showing plots of land which is used by Architect. Walls, foundations, services etc. may be placed relative to the boundaries. If the Architect changes something that was on the town plan i.e. the data passed to the architect - there is usually some process of notifying the owner of the town plan/map (so they know of the change- as it may affect others)<br />
- an architect defines a walls to be built by a carpenter. The carpenter works out where the studs, braces etc. and nails will go (these details are not normally passed back). If the location of the wall varies from the plan for some reason then dealt with by a process of notifying the owner of the building plan (it isn't just feed back into the plan - because the implications are not known).<br />
<br />
IT frequently asked about round-tripping. Which may be possible - but I suspect seldom makes sense because as one descends down from business and conceptual objectives through to implementation and technical details - it is very hard to know what makes sense to feed upwards.Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-77301292714522349462013-11-28T16:07:00.001-08:002014-10-28T17:25:18.889-07:00The Peter Principle and Enterprise Architecture<br />
<br />
It seems to me that many Enterprise Architects have been promoted from technical and design roles they were excellent at to knowledge management roles and business transformation roles that are poor at. The poor at these roles because they lack both the skills and the inclination.<br />
<br />
They make not even be aware of what Enterprise Architecture is really about - that is to say they may not realise:<br />
<br />
<ul>
<li>Enterprise Architecture is about the business - so an understanding of business products, services, capabilities, plans, goals, strategies etc. should be their initial focus (if you don't get those right the details don't matter)</li>
<li>Enterprise Architecture is NOT about Architects - and can't be done by Enterprise Architects per se. </li>
<li>Enterprise Architecture is about managing and applying knowledge about the enterprise across the enterprise i.e. it is an ongoing process </li>
<li>most methods advocated for Enterprise Architecture haven't worked, don't work and won't work.</li>
<li>Enterprise Architecture is not SW Engineering (or SW Architecture) - it is in essence not even design or architecture per se. The "A" word describes the knowledge NOT an activity.</li>
</ul>
So you turn a wonderful technician - whose main interest are in technology i.e. not business; design i.e. not planning; having knowledge not managing knowledge; in what they do i.e. not what other people do, (not in changing the behaviour of the organization) - will struggle.<br />
<br />
They will struggle even more if they think<br />
<ul>
<li>Enterprise Architecture has worked well in the past, so they should keep doing that</li>
<li>Their role is to design (i.e. to architect) not to establish a approaches and solutions which allow architectures to emerge, be recorded, be analysed by a disparate community</li>
</ul>
<br />
This combined with no concrete objective (i.e. business relevant bottom line influencing measures) means that they survive happily with their "emperor's new clothes" artefacts based on the lastest abstract framework, method, etc.<br />
<br />
They will skill fully apply Dawkin's Law of the Conservation of Difficulty - by advocating new "frameworks" and terms e.g. "viewpoints" and referencing people to abstract academic discussions rather than just using simple terms, plane english, simple approaches and just get on with what is in fact quite a simple exercise - if approached with the right mind set and solutions.<br />
<br />
<br />
<div style="-webkit-text-stroke-width: 0px; color: black; font-family: 'Times New Roman'; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;">
</div>
<br />
<div style="-webkit-text-stroke-width: 0px; color: black; font-family: 'Times New Roman'; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; margin: 0px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;">
</div>
<ul>
<li>Peter Principles: see: http://en.wikipedia.org/wiki/Peter_Principle</li>
</ul>
<br />
<br />
<ul>
<li><i><span style="background-color: white; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: x-small;">Dawkins's Law of the Conservation of Difficulty states that obscurantism in an academic subject expands to fill the vacuum of its intrinsic simplicity. Theoretical physics is a genuinely difficult subject. Envious disciplines, which I shall not advertise, conceal their lack of content behind billowing clouds of deliberate obscurity.."</span></i></li>
</ul>
<br />
<br />
<br />Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-46662874141573817342013-11-27T13:47:00.001-08:002013-11-27T13:47:14.074-08:00What is wrong with TOGAF in practice.TOGAF is like a religion, so one has to be very careful about saying anything against it. But ...<br />
<br />
There are no real facts to suggest it works in practice. Most TOGAF initiatives fail, and have failed for a decade, but everyone pretends else-wise and says the next version will be better.<br />
<br />
TOGAF has hang overs
from its origin, originators and vendor sponsors - most of whom want to treat EA as if it is a super solution architecture (or even SW Engineering approach) which it is
not. So they suggest iterations - which make perfect sense so
projects/SW - but are ill-suited to architecture and governance activities which are processes (i.e. continuous and incremental not cyclic and iterative). This is also to mistake EA for EA implementation (which is obviously a different thing entirely) just as using/applying knowledge management is a different thing from implementation a knowledge management solution/approach.<br />
<br />
TOGAF places requirements at the centre (which makes sense) but provides almost no
information on how they should be dealt with (or what in fact they are);
etc. And I suspect in their hearts they mistake business for SW requirements like most of the industry.<br />
<br />
But putting all this aside the real issue is that TOGAF is just too abstract to be useful. What it says is often true, but is so facile as not to be useful.<br />
<br />
If one wanted to implement Accounting one could:<br />
a) implement an accounting system and immediately have a way to generate invoices, track debtors, apply tax codes, and have many reporting options (as starting points). One could then extend and adapt the system to meet any unique or specific needs.<br />
b) read tomes on the locally applicable accounting methodology and tax codes and create an accounting practice using a mix of word documents, spreadsheets, etc. and perhaps creates one's own database. Then would could try and develop charts, reports etc. The system might work well for an individual who understood it well and it would keep teams of book keepers (often employed as consultants or contractors busy).<br />
c) read an abstract method that encompasses the principles of all accounting methods globally with a set of abstract high level steps and building blocks - expressed so as not to relate to any country, organisation, domain, sector or system. It would be full of abstract aphorisms and concepts most of which make sense at some level - but provide precious little practical and pragmatic advice on what to actually do tomorrow.<br />
<br />
The same is true for EA. As architects love abstraction, anything to get away from the business and business value, they always seem to favour c). Which is why they gravitate to TOGAF.<br />
<br />
The challenge for many with a) is that it demystifies EA and makes it a prosaic thing anyone can use without needing to read a foot of paper on abstractions, frameworks, taxonomies, reference models, etc. What architect will go for that?<br />
<br />
<br />
<div>
<br /></div>
Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-3199835766893736982011-07-14T14:22:00.000-07:002011-07-14T14:42:41.765-07:00EA as a set of vectors.<div>This is kind of interesting: http://www.infoq.com/news/2011/07/ea-as-vectors. </div><div><div><br /></div><div>I am sceptical of the need to introduce quantum physics into the equation. It immediately brings to mind Dawkins law of the conservation of difficulty: <i>"Dawkins's Law of the Conservation of Difficulty states that obscurantism in an academic subject expands to fill the vacuum of its intrinsic simplicity. Theoretical physics is a genuinely difficult subject. Envious disciplines, ...conceal their lack of content behind billowing clouds of deliberate obscurity".</i></div><div><br /></div><div>However I do think that it indicates some leading thinkers are starting to focus some key things I am focused on:</div><div>- complexity and the need to deal with it (<a href="http://ea-in-anz.blogspot.com/2007/11/need-to-manage-complexity-better-in.html">http://ea-in-anz.blogspot.com/2007/11/need-to-manage-complexity-better-in.html</a>)</div><div>- problems with the silo lense of a projects (<a href="http://ict-tech-and-industry.blogspot.com/2008/08/projects-are-artifical-constructs.html">http://ict-tech-and-industry.blogspot.com/2008/08/projects-are-artifical-constructs.html</a>)</div><div>- organizations are reactionary (<a href="http://ea-in-anz.blogspot.com/2008/07/focus-on-ea-is-inversing-proportional.html">http://ea-in-anz.blogspot.com/2008/07/focus-on-ea-is-inversing-proportional.html</a>)</div><div><br /></div></div><div>What I am proposing are specific solutions and methods that address these issues and provide enterprises some key capabilities a way of: </div><div>- dealing with complexity and making behaviour less subject to natural reactionary influences (e.g. less subjects to the persuasive, but illogical, narrative of powerful individuals), by allowing concepts to be made explicit and related in what call the "democratization of transformation"</div><div>- providing a holistic view of transformations and a virtuous cycle of improving understanding e.g. by allowing all initiatives to be related to a view of the enteprise and feedback into that view - starting with all business cases and requirements being expressed in terms of a common shared view.</div><div><br /></div><div>Enterprises do think in time frames. These timeframes may be referred to as states. They are not states in the sense that an object modeller thinks of the states of an object e.g. a switch "on" or "off". That are states in the sense of stages of progress in views of something at a point in time, recognising that a journy is in progress. I have said for a long time that the term "future state" with the definite article is illogical, there is not a single "future state" their are a continuum of states. This doesn't mean we shouldn't set targets for where we should be at points in time.</div><div><br /></div><div>"... A project or whatever doesn’t change the organisation from ‘current state’ to ‘future state’: instead, it provides a vector that points towards a particular direction at a particular speed. The vector does sort-of imply a ‘future state’ at an arbitrarily-chosen future point in time, but that kind of frozen-time snapshot belies the dynamics of what’s actually going on. And vectors intersect: hence whilst a single vector may point to a ‘future state’, the interaction of all the vectors will inherently take the overall system someplace else."</div><div><br /></div><div>[Many projects are influencing what things like look in at different points in time future]</div><div><br /></div><div>"... The value of a “to-be” architecture is then primarily to help us understand the benefit being realized by the steps along the way. ..."</div><div><br /></div><div>"... And EA needs to understand the complex interaction between many different changes. A typical enterprise is teeming with lots of different change initiatives, some of which may be formally constituted as "projects". ... these projects and other change initiatives interact (compose themselves) in usually unpredicted and possibly unpredictable ways. ...The ability of complex systems to preserve their identity and deep structure in the face of efforts to change them has been studied by many systems theorists..."</div><div><br /></div><div>[Many projects are influencing things and we need to try and understand their net result and their interactions. We also need to recognise complex enterprise are intrinsically reactionary]</div><div><br /></div><div>"... view modernization as a more holistic and multidimensional activity which plans and delivers a progressive transformation of the As-Is business through a series of maturity states on a number of (yes OK) vectors"</div><div><br /></div><div>[We need a more holistic view]</div>Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-91190124582042763392011-07-06T20:31:00.000-07:002011-07-07T21:06:44.716-07:00What we can learn about Requirements from Engineering<div>This item (<a href="http://www.dataweek.co.za/news.aspx?pklnewsid=39316">http://www.dataweek.co.za/news.aspx?pklnewsid=39316</a>) focuses on engineering requirements and solution vs enterprise requirements and solutions. </div><div><br /></div><div>Nevertheless some of the issues they deal just as relevant at a business or enterprise level, as they are hard to deal. </div><div><br /></div><div>They are mainly hard to deal with as a result of misapplication of techniques that are well suited to engineering electronics (or software) but very poorly suited to architecting a business. These techniques are dragged into the enterprise requirements domain by technicians or consultants. It is as if we have allowed the languages and techniques of the plumber, or the electrican to be foisted on the town planner.</div><div><br /></div><div>Extracts from the item below in italics with my comments</div><div><br /></div><div><i>...focused on requirements and the proper management of requirements throughout the process.</i> [yes, obviously critical. So it is pretty why a static document e.g. a requirements document won't do the job]</div><div><br /></div><div><i>... requirements must be captured, reviewed and validated, managed and traced to design implementation and verification activities. .... a checklist of criteria against which you review the requirements .. a method to link requirements to the design implementation...</i></div><div><br /></div><div>[Yes all necessary. At an enterprise of business level I refer to "Acceptance", "Acceptance criteria" as the process use to Verify results. We use this terms because it is business and contractually oriented term i.e. to distinguish from whatever testing/validation engineers (or suppliers, or sub-contractors) might seek to do.]</div><div><br /></div><div>... Tracing requirements to design implementation and verification results </div><div><br /></div><div><i>[made difficult by]</i></div><div>... requirements can be volatile <i>[i.e change. Obviously they change]</i></div><div>... the mechanism to capture requirements is disconnected from the design environment <i>[in a business context one needs to ask why. Really what they mean is that the requirements are disconnected from the engineer environment and there is no discrete design environment per se. That is why we focus on Solution Management and ensure the management of the solution discrete from the engineering of the elements of that solution. A lot of the complexity in business technologies results from failure to define and manage this boundary]</i></div><div><br /></div><div>... often takes an expert to do any sort of ‘management’ of the requirements <i>[in business context this is simply not viable because we need the business knowledge to define requirements. We must find a way they communicate and manage their needs]</i></div><div><br /></div><div>... the implementation and verification of requirements occurs within a variety of environments and tools, each with their own language, format, process, location and experts<i> [again in a business context this can not be case with acceptance of a solution by a business user]</i></div><div><br /></div><div>... link requirements from the highest system level to the lowest-level implementations of hardware and software. <i>[and what businesses need is to link requirements from the highest level of the business to the lowest level component that they pay for discretely. Things beneath this level are necessarily encapsulated be the bespoke of off the shelf]</i></div><div><br /></div><div>... Requirements changes, and their downstream impact, are all highlighted ...</div><div>... Requirements validation checklists are both built-in and customisable</div><div>... Requirements traceability is automated and up-to-date with the design </div><div><i>[yes, yes and yes]</i></div><div><br /></div><div>... After all, what company wants to produce a design that does not meet its requirements? What company wants to stand up in front of their customer and say “We have finished your design, but it does not do exactly what you want.” </div><div><i>[Or we have completed your expensive projects but they have not met the shareholder's or stakeholders requirements to produce value or outcomes]</i></div><div><br /></div>Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-46665553403213067822011-04-06T18:52:00.001-07:002012-04-12T22:32:27.066-07:00Challenges with TOGAF<div><span style="font-size: 100%; ">Some problems with TOGAF:</span></div><div><span style="font-size: 100%; "><br /></span></div><div><span style="font-size: 100%; ">Process not a project - People tend to think of it a cyclic set of sequential steps (like a SDLC waterfall) rather than a continuous process with parallel contemporaneous steps (more like an agile approach to development). Iteration is an attempt to overcome the limitations of waterfall approaches and allow management gateways to be implemented; and static artefacts (documents) to be used as the means of communication. This is probably because it is overly oriented toward solutions architecture (and arcane languages like UML).</span></div><div><br /></div><div>A generic approach not a specific way to do anything - It is a generic approach that doesn't say specifically what to do to solve any specific business problem, or deliver specific business value. That is not to say it isn't correct - it is to say it is hard to follow.</div><div><br /></div><div>A method unimplementable without a solution - It is like teaching someone the principles of accounting and then asking to do the accounting for a large organization using Word and Visio to create the invoices and do the reporting.</div><div><br /></div><div><span style="font-size: 100%; ">Continuous change and dynamic architecture - Yes. Versioning is not the answer, the answer is that all people all access information and that artefacts are produced dynamically representing the current understanding.</span></div><div><br /></div>Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-83623899967699206432010-05-23T18:23:00.000-07:002010-05-23T18:43:06.090-07:00Horses for coursesI see Methods and Tools recent poll mixed results for UML http://www.methodsandtools.com/dynpoll/oldpoll.php?UMLPoll2<br /><br />I would suggest few doubt that UML (or UML like OO analysis) is useful. The key things are to determine when it most useful and when it is not particularly useful. It is strange for me to be writing in support of UML as I more usually pointing out that it does fit well in the domains I predominantly work on now e.g. strategy and strategic architecture.<br /><br />That only 14% of people use UML on all projects makes sense (perhaps they all have complex OO projects), that 45% of people use it, or some of its techniques, on some projects makes ever more sense. <br /><br />That 11% of people have abandoned it suggests to me that it has been misapplied. Way back when started reading what is now Methods and Tools it was called JOOP (Journal of Object-Oriented Programming) my focus was very much of OO analysis and development methods - but ever since those days I have seen SW developers (or ex developers) promote the use of UML where it is poor suited. They have their hammer (UML) and every problem is treated a nail. This has not helped UML.<br /><br />The Agile method may be suitable for some projects but I don't see it as well suited to large complex initiatives, involving many parties and systems that need to be supported and extended over many years. This is because it fails to record or communicate complexity to the various stakeholders who need to participate over time i.e. who are not party to the face to face conversations, and don't read the code.Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-37050173839805733502010-04-18T15:25:00.000-07:002010-04-18T15:26:33.258-07:00How to align analysis and strategyI saw this "http://www.alinement.net/component/content/article/42"<br /><br />My issue with this article is that it identifies a problem - and present no real answer.<br /><br />This item raises two issues:<br />- Ambiguity in business strategy significantly impedes BA work and an uncertain strategy will delay getting clear answers to specific questions. <br />- An ability to make decisions where trade offs are required mean analysis and design impossible.<br />In both cases what is required is semantic precision. <br /><br />BA could enhance their role if they applied semantic precision. Natural language and using word documents as the means of maintaining knowledge militates against this. The advice given covers some areas where precision is required - but gives no clues as to how to go about being precise.<br /><br />Few would disagree that we need to be: <br />- Clear about the objectives and constraints (e.g. time-horizon) <br />- Understand the reasons for and importance of requirements (and know which are mandatory, which highly desirable etc.) i.e. record reasoning and priority<br />- Define the appetite for risk and innovation (e.g. how creative does the solution need to be) and in fact understand what is wrong with the current state (i.e. the implications of ‘doing nothing’)<br />- Identify and facilitate the resolution of conflicts between stakeholders - which must start by making such conflicts explicit e.g. A thinks XYZ is priority 3, B thinks XYZ is priority 7<br />- Concisely and specifically document your understanding of the strategies. [Using what semantics?]<br />- State sensitive assumptions. [And presumbaly relate them to something?]<br /><br />The question is how can we: be clear, record reasoning and priority, make explicit relationships and record strategies explicitly.<br /><br />The strategy should not be to put things into "words". It should be 1st to define a small canonical set of concepts (words, relationships) and use these with precision - and ontology if you like. This would allow us to eliminating synonomous terms, relate concepts explicitly etc. This allows us to be clear about what concepts are we dealing with and how do we relate concepts. How do we deal with priorities (and networks of prioritised items).<br /><br />For example how do we rate importance e.g. is a requirement marginally critical to a high priority business goal more important (less important or equally important), than a requirement very critical to a medium or low priority business goal.Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-19091141064642132142010-04-09T18:49:00.000-07:002010-04-09T19:06:01.411-07:00The strange idea of requirements before design, and design before constructionI continually dumb founded that other experienced and intelligent people thing that they leap into the use of a modelling tool to record concepts and analysis without being clear on the requirements or doing design. At present I am focused on modelling of enterprise - their operations, technologies and related transitions and initiatives. I always emplore people to:<br />1. gather the requirements (e.g. the questions they want the model to answer) BEFORE they start thinking of the design of the model<br />2. sketch out a rough design in some manual method (on paper, on a white board i.e. on anything but a computer modelling system) and get that design clear in their heads.<br />3. go about modelling.<br /><br />But people presented with a modelling tool inevitably leap to 3. Some argue they implicitly know the needs (which I seldom buy) and some say they design best using computers (which I don't buy either).<br /><br />I have written in other items in detail about why the way model something depends on the answers to be asked of the model. Which I won't recap on here. <br /><br />AN ANALOGY FROM MY PAST<br />A CAD system, and in fact architectural drawing themselves, are models of a proposed or existing reality. They are way of communicating and analysing reality. <br /><br />Once in my distant past after leaving Architecture school I specialised in CAD systems for architects. After a decade of using them (and at that stage I was as proficient as anyone in the world) with them them I became more and more convinced that in the vast majority of cases the use of these tools impairs the cognitive processes associated with conceptual design. <br /><br />The conceptual design was better done on the back of an envelope, scratched in the sand of modelled roughly from wood and clay. I think this is for deep seated reasons to do with human cognitive processes and design. I think it has to do with issues of gestalt and post cognitive dissonance and the tendency for electronic tools to require greater precision (dimensional, semantic etc.) than should exist at the early stages of design - i.e. where it is better to leave some things loose, woolly, undefined/less defined.<br /><br />This is not to say that they should not be used - but they should use to elaborate a design (not conceive one).Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-37732722658998895472009-12-22T12:38:00.000-08:002009-12-22T12:39:45.189-08:00BPM findings based on AIIM reportBPM:<br /><br />IS<br />- not a single software product or even as a suite of related software tools. It is management practice which might utilize a number of dedicated software mechanisms. <br />Involves<br />- an intrusive technology changing and re-shaping BP for higher performance. <br /><br />MAY INVOLVE<br />- integrating applications, taking in electronic forms and edocuments, populating transactional databases and providing a single point of interface for users. <br />- process modelling and simulation, reusable process modules, and process monitoring and optimization. <br /><br />DRIVERS AND RETURNS<br />- most important drivers are: cost savings from improving process throughput and reducing process steps; followed by Improving accuracy and repeatability<br />- accounts payable and accounts receivable processes showed the strongest success factors, followed by customer support cases, proposals and contracts, and claims processing.<br />- approx 1/2 of organisations achieved payback of their investment in BPM tools in 18 months, and 3/4 with 24 months.<br /><br />LEADERSHIP<br />- 1/3 of the time BPM projects are lead Line of Business managers and in 1/3 IT take the lead.<br />- The strongest indicator for successful BPM processes is the presence of an existing process owner.<br /><br />CHALLENGES<br />- integration with other systems is the biggest technical challenge <br /><br />USAGE based on organisations surveyed<br />- 1/3 apply BPM to scanning all incoming mail.<br />- few currently extending managed processes across the supply chain, but many plans to.<br />- few are currently outsourcing BPM-enabled processes but many plan to<br />- 11% use BPM functions in SharePoint, but 3 times as many plan to.<br />- Spending on BPM SW should increase, and spending on BPM services should increase significantly.<br />- 1/3 look to buy their BPM tools from their existing ECM supplier, with 1/4 go for best-of-breed tools, and 1/4 preferring dedicated BPM suites.<br /><br />Source <br />http://www.ebizq.net/blogs/bpm_insights/2009/12/-pdrtjs-settings-159850-post-1700-id.phpMichael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-77029600683781859952008-11-30T16:11:00.000-08:002008-12-02T14:50:52.026-08:00Characteristics of professional transformation and optimisation practicesProfessionals will see to work organisations that they can be proud of, that excel, that have integrity, that learn, and with people they can respect (and who respect them). And I don't mean this as some kind of platitude to be trotted out for the benefit for impressing customers, partners or the market, by some marketing person who could just as easily be working for a brewer or a manufacturer.<br /><br />These practices are lead and directed by visionary people - who practice i.e. do (not by people who spruik, not accountants - unless of course it is an accounting practice). This is true of all great practices. These people genuinely believe in what they do, and evangelical about doing things better, smarter, etc. and lead from front. They need these characteristics to overcome the inherent resistence that they will encounter from those who have built their reputations doing things in some outdated way. This is true in any real profession.<br /><br />In all cases the business leader(s) would actively and continuously seek way of doing things (steps, tools etc.). The leader would engage other professional around who specialised in different areas and oversee: consistency, quality and learning for the organisation as a whole. This of course requires a real and genuine interest in the domain (in doing - not selling), talent, great self discipline, consistency, honesty and bravey etc. These practice would select people would have talent, intelligence, skill, be willing to learn, change. They would meet challenges, take responsibility, and be persistent. Those who were most highly rewarded would be the professionals leading the practice (not sales, marketing, general management, or accounting types). You can see in established professions: Architectural, Engineering, Medical, Legal, etc.<br /><br />I am interested in strategic transformation and optimisation practice. In practices oriented at this there needs to be a focus on things such as:<br />- strategic planning and architecture: so what to deliver would be known.<br />- project and design management: so it would be possible to manage delivery<br />- technology and product selection: so the best materials and components could be used (rather than being in some vendors pocket)<br />- design and constructions methods: as often industry best practice is less than ideal<br />- operations: both because often industry best practice is poor and because ensures an understanding of operational realities (and changes and improvements must be able to operationally effective).<br /><br />Sadly many IT oriented practices that claim to focus on transformation and optimisation are not lead this way. This results is pitiful best practice, over pricing, under delivery and lack of any real will to improve or change. I have heard every excuse in the book as to why IT is different. The sad truth is that IT has historically been a sales and marketing driven industry lead by persuasive, charming, well connected people. They think business is best done over meals, and drinks and social events are the build professionalism. Secretly they look down on the professionals they have in their ranks. Over time this means that the best and brightest professionals leave.Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-87913680754917171682008-06-25T15:32:00.001-07:002008-06-25T15:40:44.833-07:00Why organisations struggle to improve how they manage requirements<div style="text-align: center;"><span style="font-style: italic;">Why do organisations struggle to improve their approach to managing requirements. </span><br /></div><br />Essentially because the industry doesn't present a common view of best practice - and frequently doesn't distinguish between different approach to requirements management i.e. high level vs low level, and approaches for low level requirements management.<br /><br />Ideally at a high level enterprises should have a common way of defining requirements (and assessing that they are met). At lower levels the methods should diverge depending on how the requirements are to be met - and the role enterprise needs to be play.<br /><br />We could think the ways that requirements might be met under four broad headings: development (where major components of software are developed), integration (where a number of essentially existing components are integrated), package customisation (where essentially an existing solution is customised, configured or extended) and package off-the-shelf (OTS)<br /><br />Development may be when enterprise builds a solution inhouse e.g. developing in Java, C# etc. (the solution will fit like a glove i.e. and is bespoke). This is usually done when no OTS packages meets the requirements and/or the business seeks to achieve unique market differentiation based on the solution (software). This may or may not involve an adjustment to how the business operates.<br /><br />Package customisation is where a package or service (such as SAP) is purchased and it is customised, configured or extended (as little as necessary). In this case there is also usually some recognition that some adjustment to how the business operates may be entailed (as presumably the package reflects industry best practice).<br /><br />Package OTS is where a product or service is used as purchased (no changes a made) for example MS Word. This is usually done where an enterprise does not seek to achieve competitive advantage through the use of the tool e.g. few business seek to differentiate themselves based on how well they use a word processor.<br /><br />Integration may involve all of the above and how different components (including external services) from each area work in concert.<br /><br />It should be clear that the ideal approach to requirements in each of these fours area differs. The failure in most requirements management approaches is that the lower level methods pollute the higher level approach to requirements management (by way of analogy - the way the plumber or electrician, or block layers needs to define what they doe, and how they notate their detailed designs, is foisted upon people who wants to describe that they want a new garage).<br /><br />The approach to requirements management also needs to align with the approach to project management. This introduces another issue i.e. project management in IT.<br /><br />This failure is matched with failures to recognise the difference between project management in IT vs project management for buildings. The reality is that in IT the requirments and specifications often evolve right to the end. This because what people want to do with the technology elements is partially determined by what the technologies can do i.e the technologies change behaviour. To pick to generic consumer oriented examples: a GPS navigation phone changes how one navigates, a video conferencing phone changes how one communciations (as does a texting/SMS phone, instant messaging etc.), Google et al changed how one finds things. If we constrast this with buildings this is far less the case i.e. we pretty well know exactly how we want to use say: a toilet, a door, a bed, a bed room and lift.<br /><br />In IT delivery a great deal of the time is focused on understanding precisely the requirements are, and therefore what the design is (including engineering calculations), and what construction is required, and how things should be tested. In buildings the requirements are far more precisely understood at the start, the design is well articulated and precise before construction starts, the testing is usually more obvious (or it is covered fairly well defined industry conventions), etc. In buildings the scope very well defined and the focus on project in buildings is far more on costs, time and variance - whereas in IT the scope is seldom well defined at the start, and the focus in project management is on management the refinement of scope (and cost, time).<br /><br />Asking most organisations for whom this not their main focus how the they want to manage requirements is probably unrealistic i.e. it is a bit like a building architect asking a home owner how the plans should be drawn up, or an electrician asking the home owner how the electrical diagrams should be drawn.<br /><br />So what is needed is to show some leadership with clients in explaining how requirements can be managed - and how this related to detailed SDLCs, approaches to project managment, and approaches to aspects of enterprise architecture (e.g. standards compliances, skills management etc.).<br /><br />A starting point for requirements must be how the business operates or seeks to operate. This in turn needs to be ground in the business drivers and constraints (which include technological, organisational and environmental considerations).Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-59957650040143716842008-02-06T19:07:00.000-08:002008-02-06T19:11:38.646-08:00Process Component Models<div style="text-align: center;">(prompted by <a href="http://www.infoq.com/articles/process-component-models">this item on PCM</a>)<br /><div style="text-align: left;"><br />This is a selective summary.<br /><br /><span style="font-weight: bold;">BPEL is not great for BPM modelling</span><br />BPEL's association with BPM is problematic from the viewpoint of the BPM modellers (i.e. based on good marketing). The only association is that a BPEL process can be shown as a diagram and that the language has support for wait states.<br /><br />The BA is supposed to be non-technical, so the chance that the activities in the model correspond to available WS is small. BPEL is block structured, and this is too limited for modelling purposes. Analysts need the freedom to draw boxes and arrows, which always leads to graph structures and arbitrary cycles. A BPEL process doesn't have a notion of transitions. So usually, it's not possible to keep the analyst's analysis diagram in tact when translating into a BPEL executable process. This is exactly why the mapping BPMN to BPEL is hard and has so many limitations.<br /><br />Another problem is the limited data manipulation capabilities. Extracting pieces of content from an XML document is most of what you need in service orchestration. But for BPM, often a lot of data processing needs to be done in between steps of the process.<br /><br />If you consider using BPEL for BPM, ou should ask yourself is whether you want your core business process data in the ESB. The domain data that the BPEL engine needs to maintain is usually stored in relational databases. The information in your core business processes must be easily linked to the domain information in the relational databases. This information should be included in the domain model in a database. Not inside the BPEL engine. BPEL doesn't prevent that kind of information to be stored in the domain model database, but it makes it harder. You might have to implement a special web service to get the customer reference stored in the domain model. So BPEL seems to make it easy to get your domain model information partitioned.<br /><br />BPEL is a good technology for scripting new services as a function of other services. But that it doesn't deliver on its promises for BPM, for which it is currently known. That doesn't mean that BPEL is bad - if you use it as an integration technology to build coarse-grained services out of smaller grained services.<br /><br /><span style="font-weight: bold;">BPMN for BPM modelling</span><br />As an analysis language to help with the documentation of a business process BPMN is a very good option. A BPMN diagram improves communication between analyst and developer, but the developer still remains responsible for all the technical details that are a part of the executable process.<br /><br />A BA creates a description of the business process including a diagram. Then the translation needs to occur to the executable process language. The impact of that translation will depend on the analyst's technical skills and the capabilities of the executable process language. In any case, the goal is to have a minimal impact on the diagram so that the BA recognizes and understands the diagram of the executable process. Note that the diagram is only the tip of the iceberg, because a lot of technical details might be included in the executable process that are of no interest to the analyst. After the translation, the executable process is software, and therefore the non-technical BA is only allowed to see it in read-only mode.<br /><br />The great advantage that BPM brings here is that analyst and developers are given a common language. The BPMN diagram helps to speed up the communication between BAs and developer. This indeed creates the 'agility' that is credited to BPM. But the illusion that BAs can just edit diagrams and press the 'Publish to production' button is optimistic and unrealistic<br /><br />Portability at the modelling level is at least as important as portability on the implementation (executable processes) level i.e. portability of process logic from one platform to another is important but so is portability of people allowing us to move our skills from one process design tool to another. BPEL may be able to help with the first goal, but it's not appropriate for the second. When BPMN becomes widely supported it will make people's process design skills portable.<br /><br />If process modelling is bound to executable processes, the graphical representation of the process should not contain too much information. Trying to express too much detail in the graphical diagram requires everyone to the details and means that there is less chance they will match with the executable language.<br /><br />Process languages (executable and non executable) differ too significantly to unify them in graphical process designer based on BPMN. For each process language, a BPMN subset can be defined that matches well with that language. The designer tool should support the specific structures of the language and the appropriate finer details directly.<br /><br /><span style="font-weight: bold;">Round tripping</span><br />The mapping approach of BPMN has lead to the mistake of round tripping. The idea of round tripping is the continuous switching between the BPMN analysis model and the executable process. The BA works in a modelling language like BPMN, using the graphical notation and the BPMN properties and the developer works in an executable language like BPEL. The problem with this approach is that in practice, it turns out to be way too hard to maintain 2 sets of properties.<br /><br /><span style="font-weight: bold;">BPMN and BPEL mapping</span><br />BPMN is graph based, where as BPEL has a composite structure without transitions that corresponds to a tree. Secondly, the concurrency models differ substantially.<br /><br /><span style="font-weight: bold;">Process component models</span><br />The idea is that activities in a process graph are linked to a component that implements the runtime behaviour of that activity in a general purpose programming language. Each activity type in a process language corresponds to one implementation component. With this approach a common base layer is extracted from the BPM and workflow technologies.<br /><br />Because they can support multiple process languages, process component models reduce the importance of the individual process languages. Instead, they let developers select the most appropriate executable process language for each process. This improves the separation of concerns between analysts and developers over a situation where a BPM engine only supports one process language.<br /><br />In this perspective, we can identify 4 levels of detail, which perfectly fits with a smooth transition from analysis model to executable process model: 1. Process graph structurel; 2. Activity type selection (corresponds to the runtime implementation); 3. Configuration of the runtime implementation; 4. Plan B: Custom coding of an activity<br /><br /><span style="font-weight: bold;">Conclusion</span><br />BPEL is an executable process language, which is good for integration purposes, but it's not suited for supporting Business Process Management cause of its tight coupling with technical service invocations. BPMN serves the analysts in drawing analysis diagrams, but it's not executable.<br /><br />We need to start by making a better distinction between analysis process models and executable process models. Once we abandon the idea that non-technical BAs can draw production-ready software in diagrams, we can come to a much more realistic and practical approach to business process management.<br /><br />When linking an analysis process model with an executable process implementation, the clue is not to include too many of the sophisticated details of the analysis process notation in the diagram. By using only the intersection of what the analysis language and the executable process language offers, a common language can be created for the BA and the developers, based on one single diagram.<br /><br />Different environments and different functional requirements require different executable process languages. The current idea that one process language would be able to cover all forms of BPM, workflow and orchestration is just too ambitious. And if such an effort would succeed, the resulting process language would be way too complex for practical usage.<br /><br />New technologies create a component model so that activity types can be build on top of a common foundation.<br /></div></div>Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-47374702322227756442008-01-22T18:16:00.000-08:002008-01-22T18:21:24.749-08:00Services a discipline<div style="text-align: center;">(<a href="http://www.research.ibm.com/journal/sj/471/glushko.html">based on IBM SJ paper</a>)<br /><div style="text-align: left;">The following are some notes of interest:<br /><br />Economic statistics conclusively demonstrate that global economies are increasingly based on information and services, and that demand is growing and exceeding supply for people with the knowledge and skills to be effective workers in this new economy. A consensus is emerging that the cumulative and interconnected innovations in information and computing technology, industrial engineering, business strategy, economics, law, and elsewhere cannot be described and understood by a single academic discipline.<br /><br />Many of the concepts, techniques, for service design and operations originate in and emphasize person-to-person services. However, they do not fit well when person-to-person services are replaced or complemented by self-service, and hardly fit at all for automated IT services provided by one IT process to another. We might conclude that the word "service", in person-to-person services, service architecture, are homonyms and not try to unify them conceptually and methodologically, but we will make little progress toward a service science if we do not find abstractions that unify them or establish clear boundaries between them.<br /><br />Many seem to view it as unquestioned dogma that a customer-centric approach is inevitable and essential.However, while a focus on the customer and customer interactions (the front stage) has been shown to contribute to quality in person-to-person services, it is not straightforward to apply the same focus to the design of self-service and automated information-intensive services.<br /><br />The questions that can be asked about a service science inquire about some activity in the life cycle of a service. We can ask, How is a service: designed, planned, forecasted, specified, provisioned, composed, integrated, deployed, delivered, managed, certified, used, reused, evaluated, optimized, archived, etc.<br /><br />This list, while far from complete, but illustrates that a very large number of activities or processes could be important parts of the life cycle of a service or set of services. Because services can be people-to-people, people-to-technology (self-service), or computer-to-computer (e.g., Web services), a variety of methodologies apply to the service life cycle. These methodologies partition the life cycle differently, use different words to talk about each activity, and make different design decisions and trade-offs.<br /><br />When different disciplines and perspectives come together, the outcome is unpredictable. One discipline can become dominant and absorb parts of the others, or the overlapping pieces can break away and form a new field. But if the new field never becomes more than the sum of its parts, it can fade away over time. Occasionally, however, a new and important discipline emerges as a synthetic combination. The multidisciplinary or transdisciplinary character of the transition to a service-dominated economy makes it intrinsically difficult to define what a new, unifying discipline might look like. We might posit that a new and synthetic discipline of service science is desirable, but we should not assume that it is inevitable.<br /></div><div style="text-align: left;"><br /></div><br /></div>Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-62686530317801268962008-01-22T14:20:00.000-08:002020-06-04T17:29:56.799-07:00Product Management – Overview and concepts<h2 style="font-style: italic;">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Product Management – Concepts </span><span style="font-family: Arial, Helvetica, sans-serif;">– circa </span><span style="font-family: Arial, Helvetica, sans-serif;">2000</span></h2>
<span style="font-family: Arial, Helvetica, sans-serif;"><i style="font-style: italic;"><span lang="EN-GB" style="font-size: 14pt;"><span class="msoDel"><del cite="mailto:Michael%20Ellyett" datetime="2003-05-23T12:42"></del></span></span></i><span lang="EN-GB" style="font-weight: bold;">Introduction </span></span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB"><br /></span></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB">My focus has always been on quality, continuous improvement and excellence of execution. </span></span><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Delivering services using well defined approaches<a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn1" name="_ftnref1" title=""><span class="MsoFootnoteReference"><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[1]</span></span></span></a> is critical to achieving these things. </span><br />
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif; font-weight: bold;"><br /></span>
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;"></span><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Approaches </span><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn3" name="_ftnref3" style="font-family: Arial, Helvetica, sans-serif;" title=""><span class="MsoFootnoteReference"><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[3] </span></span></span></a><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">deliver products and services </span><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn2" name="_ftnref2" title=""><span class="MsoFootnoteReference"><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[2]. </span></span></span></a></span><span style="font-family: Arial, Helvetica, sans-serif;">Each approach has:</span><br />
<br />
<ul>
<li><span style="font-family: Arial, Helvetica, sans-serif;">a set artefacts (e.g. deliverables</span><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn4" name="_ftnref4" style="font-family: Arial, Helvetica, sans-serif;" title=""><span class="MsoFootnoteReference"><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[4]</span></span></span></a><span style="font-family: Arial, Helvetica, sans-serif;">) which there should be templates for and examples of. </span></li>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">a process i.e. a sequence of <b>Steps</b> (and sub-Steps), Steps are performed by <b>Roles</b> who use <b>Tools</b> and apply <b>Techniques</b>); </span></li>
</ul>
<br />
<span style="font-family: Arial, Helvetica, sans-serif;">This ensures services are delivered in a consistent and repeatable way, and assists in classifying artefacts and developing metrics e.g. for Steps, Artefacts, etc.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB">Highly adaptable approaches which can be easily instantiated<a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn6" name="_ftnref6" title=""><span class="MsoFootnoteReference"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[6]</span></span><!--[endif]--></span></a> and adapted allows for continuous learning. Approaches that attempt to obviate the need for judgement and experience are doomed to failure<a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn7" name="_ftnref7" title=""><span class="MsoFootnoteReference"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[7]</span></span><!--[endif]--></span></a>. Approaches can always be improved and need to constantly be assessed for gaps, areas of improvement, changes in underlying technologies or environment. etc.</span><span lang="EN-GB" style="font-weight: bold;">
</span></span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB"><br /></span></span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB">Common tooling (and language, notation, syntax and format) is key to effectively getting people using common approaches<a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn8" name="_ftnref8" title=""><span class="MsoFootnoteReference"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[8]</span></span><!--[endif]--></span></a> and managing complexity<a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn9" name="_ftnref9" title=""><span class="MsoFootnoteReference"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[9]</span></span><!--[endif]--></span></a>. Basic modelling that allow elements of types and associations between those elements is fundamental. </span></span><span style="font-family: Arial, Helvetica, sans-serif;">Models can be present in many ways e.g. tables, forms, diagrams etc. </span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Approaches</span><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;"> need to lead by owners who will act as a focal point for ongoing development of the Approach. They will also try and stay abreast of industry and academic developments and assist in knowledge transfer by understanding who is applying the approaches, what they have know and learnt, what they have produced and any problems encountered. Their knowledge will be useful during instantiation and their reviews they highlight where approaches can be improved. </span></div>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Approach owners would ideally QA all work done with an Approach until they are confident a practitioner has developed enough experience in the use of the Approach to apply it successfully.</span></div>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB"></span><span lang="EN-GB">Universal access is critical so that teams of people can work together independent of location. So r</span></span><span style="font-family: Arial, Helvetica, sans-serif;">epositories need to established that are accessible from anywhere (over the internet). All documents of record (e.g. contractual, deliverables and key supporting artefacts should in these repositories.</span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;">Critical to improving metrics is understanding the effort associated with each Step, and/or Artefacts</span><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn10" name="_ftnref10" style="font-family: Arial, Helvetica, sans-serif;" title=""><span class="MsoFootnoteReference"><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[10]</span></span></span></a><span style="font-family: Arial, Helvetica, sans-serif;">. For this reason we favour high level plans (or task lists) and the recording the effort against them. If we don't record how long a class of task or artefact has taken in the past we have no basis for estimating how long it can be expected to take in future.</span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="Bullet1">
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB">Approaches can be defined at different levels of detail. There has been much debate regarding the best format for representing the products. What we are trying to achieve is a consistent way of representing approaches. The current view is that products will be represented by:</span><span lang="EN-GB" style="font-family: Wingdings;"><span class="msoIns"><ins cite="mailto:Michael%20Ellyett" datetime="2003-05-23T12:39"></ins></span></span>
</span></div>
<ul>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Brochure – that summarises the benefits and broadly outlines the approach.</span></li>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Presentation – that summarises the approach, its objectives, challenges to be overcome and the steps to be undertaken. </span></li>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Model(s) – process models that provides an overview of process</span></li>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Document(s) and/or Wiki – a narrative describing the overall process, sub-processes and discrete steps (often with reference sources, useful tips on techniques, etc.)</span></li>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Artefact lists – derived from the approach model (and often presented with default metrics) as a spreadsheet. They may be elaborated in discrete documents.</span></li>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Artefact templates – for each artefact/model</span></li>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Artefact exemplars – for each artefact/model</span></li>
<li><span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Role descriptions – usually recorded in the approach model (may be elaborated in documents).</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Work template – a simple set of steps and schedule (steps, key dependencies etc.).</span></li>
</ul>
<div class="Bullet1">
<!--[if !supportLists]--><!--[if !supportLists]--><!--[endif]--><!--[if !supportLists]--><!--[if !supportLists]--><!--[if !supportLists]--><!--[endif]--><!--[if !supportLists]--><!--[if !supportLists]--></div>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Approaches should provide an overview<a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn11" name="_ftnref11" title=""><span class="MsoFootnoteReference"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[11]</span></span><!--[endif]--></span></a> for experienced practitioners. The approaches may be terse and to the point<a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftn12" name="_ftnref12" title=""><span class="MsoFootnoteReference"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 10pt;">[12]</span></span><!--[endif]--></span></a>. It is not expected that anyone other than an experienced practitioner, or someone mentored by an experienced practitioner can successfully apply the approaches. </span></div>
<h2>
<span style="font-family: Arial, Helvetica, sans-serif;">Approach use</span></h2>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">When a project is established we will establish a discrete project repository. Copies of standard artefacts templates will usually be put in this repository (its categories, documents types will reflect the areas/steps of the approaches)</span></div>
<div class="Bullet1">
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB">Approach model – will be either used as is or adapted as required.</span></span></div>
<div class="Bullet1">
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB">Steps – will be recorded in a plan and each step will be sized and resourced as appropriate.</span></span></div>
<div class="Bullet1">
<span style="font-family: Arial, Helvetica, sans-serif;"><span lang="EN-GB">Work and Artefacts – work will be undertaken and artefacts will be created</span></span></div>
<h2>
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Current technologies (i.e. what we should use)<o:p></o:p></span></h2>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Documents: </span><span style="font-family: Arial, Helvetica, sans-serif;">spreadsheets, word, presentations, diagrams</span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;">Models: sets of components that are related</span></div>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Diagrams: based on models where possible. </span></div>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Plans and schedules</span></div>
<div class="Text1">
<span style="font-family: Arial, Helvetica, sans-serif;">Document repositories</span></div>
<div class="Text1">
<span lang="EN-GB" style="font-family: Arial, Helvetica, sans-serif;">Generic communications: email, IM, Wiki, etc.</span></div>
<div>
<!--[if !supportFootnotes]--><span style="font-family: Arial, Helvetica, sans-serif;"><br clear="all" /></span>
<hr align="left" size="1" width="33%" />
<!--[endif]--> <br />
<div id="ftn1">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref1" name="_ftn1" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: 8pt; font-weight: normal;">[</span><span lang="EN-GB" style="font-size: xx-small; font-weight: normal;">1]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-size: xx-small; font-weight: normal;"> Sometimes called methodologies or processes.<o:p></o:p></span></span></span></div>
</div>
<div id="ftn2">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref2" name="_ftn2" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[2]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"> Sometimes called offerings<o:p></o:p></span></span></span></div>
</div>
<div id="ftn3">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref3" name="_ftn3" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[3]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"> Typically delivered in the context of a project or assignment<o:p></o:p></span></span></span></div>
</div>
<div id="ftn4">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref4" name="_ftn4" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[4]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"> I take a Miessian view of deliverables (i.e. “less is more”) and distinguish work products and deliverables<o:p></o:p></span></span></span></div>
</div>
<div id="ftn5">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref5" name="_ftn5" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[5]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"> Examples should be evaluated to see if they represent best practice<o:p></o:p></span></span></span></div>
</div>
<div id="ftn6">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref6" name="_ftn6" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[6]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"> The generic roles, artefacts and steps etc. be adapted, amalgamated, or put aside.<o:p></o:p></span></span></span></div>
</div>
<div id="ftn7">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref7" name="_ftn7" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[7]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"> Based on empirical experience (e.g. with organisations touting methodologies as silver bullets)<o:p></o:p></span></span></span></div>
</div>
<div id="ftn8">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref8" name="_ftn8" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[8]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"> Exp</span></span><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">erience shows that Word document based approaches fail and Systems oriented approaches too expensive and inflexible.<o:p></o:p></span></span></span></div>
</div>
<div id="ftn9">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref9" name="_ftn9" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[9]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"> See: The Challenges of Complex IT Projects [British computer society; Royal Academy of Engineering]<o:p></o:p></span></span></span></div>
</div>
<div id="ftn10">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref10" name="_ftn10" title=""><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB" style="font-weight: normal;">[10]</span></span><!--[endif]--></span></span></a><span class="MsoFootnoteReference"><span lang="EN-GB"> Often this is considered impractical in a plan because many tasks relate to many deliverables.<o:p></o:p></span></span></span></div>
</div>
<div id="ftn11">
<div class="MsoFootnoteText">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: xx-small;"><a href="https://www.blogger.com/blogger.g?blogID=6601708826898686511#_ftnref11" name="_ftn11" title=""><span class="MsoFootnoteReference"><span lang="EN-GB"><!--[if !supportFootnotes]--><span class="MsoFootnoteReference"><span lang="EN-GB">[11]</span></span><!--[endif]--></span></span></a><span lang="EN-GB"> Check lists, handy templates, memory joggers etc.</span></span></div>
</div>
<div id="ftn12">
<div class="MsoFootnoteText">
<br /></div>
</div>
</div>
Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-38984495814394475112008-01-21T15:23:00.000-08:002008-01-21T15:24:23.953-08:00BPMN processes and poolsn addition to describing the internal process orchestration (or control flow), BPMN can represent choreography (the message exchange between processes). In the real world, an end-to-end business process may be composed of multiple BPMN processes interacting through choreography. A single BPMN process (as opposed to multiple processes) is confined to a pool (i.e. a pool is a container for a BPMN process), is within a single domain of control, and has a start/end (where the process state is changed by a set of activities in the process). The most common reason for multi-pool processes is that an instance of one process does not have one-to-one correspondence with an instance of the other. Unlike traditional process modeling notations, BPMN puts events and exception handling right in the diagram itself, without requiring specification, or even knowledge, of the technical implementation. This business-friendly “abstract” representation combined with precise orchestration semantics lets BPMN process models serve as the foundation of executable process implementations (with implementation properties layered on top of the model, usually be IT).Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-18387854281417469742007-12-13T14:23:00.001-08:002007-12-13T14:28:10.642-08:00EA Tools AdoptionResearch from 50+ years ago grouped adopted of new technologies into five categories:<br /><ul><li>Innovators (about 2% of the population) or enthusiasts, will use a technology based on its features and do not require financial analyses before adopting a new technology.</li><li>Early Adopters (about 13% of the population) or visionaries wait until Innovators have shown a technology has merits but still are not driven by financial analysis.</li><li>Early Majority (about 33% of the population) or pragmatists need to see clear ROI analysis or ROI-based testimonials from others in a similar industry.</li><li>Late Majority (about 33% of the population) needs concrete objective ROI analysis supported by multiple sources.</li><li>Laggards (the remaining 16%) or skeptics will only use advanced technology if they have no other choice. Often new technology must be embedded in a total solution for a laggard to adopt a new technology.</li></ul>I believe the EA tools adoption is now moving from the 2nd to the 3rd of these groups.<br /><br />If you encounter an organization where innovation is the rule, you can promote the idea of EA tools based on their technical merits (and allow the innovators and early adopters to map the features to organization advantages and benefits)<br /><br />If you find early adopters and early majority users you will need to focus on the ROI and carefully map the features of into specific advantages and benefits within your organization.<br />Promoting to late majority and laggards may require you to bundle EA tools into a larger package and sell that package as an organizational solution e.g. suggesting a complete IRM for the industry (e.g. insurance, health etc.)Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-32693661633435511132007-12-09T13:01:00.001-08:002007-12-09T13:03:11.616-08:00RHE Analysis and modelling offeringsRHE offers a range of analysis and modelling services. These cover the:<br />- business strategies and plans (drivers, strategies, measures/KPIs, markets, products/service).<br />- business architectures (interactions, processes, policies/rules, information, organisation, agreements/relationships)<br />- business change (initiatives, business cases, programmes/projects, requirements)<br />- technology architectures (services/applications/components, HW/SW infrastructures, operational procedures).<br />- technology industry (vendors/products, standards, visioning etc.)<br />- technology design (SOA, objects/UML, data/ER, process/BPMN, etc.)<br /><br />RHE uses techniques semantics, and tools that allow:<br />- reference models where they exist to supporting industry benchmarking<br />- information in the different areas to be inter-related.<br />- artefacts to be produced in a variety of forms (documents, diagrams etc.)Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-69698520652258426252007-12-05T14:27:00.000-08:002007-12-05T14:29:54.233-08:00Lattix Troux Interface<div style="text-align: center; font-style: italic;">(WIP steps are)<br /></div>See rationale see (<a href="http://ea-in-anz.blogspot.com/2007/10/sw-architecture-feeding-into-enterprise.html">Enhancing EA with SW Architecture</a>).<br /><br />An overview or steps are as follows:<br /><br />1. Model the application in the Enterprise Architect - e.g. in Troux Architect define an Application (and commit the Application to the Metaverse) or create the application in Metaverse directly. In production environments will have hundreds of existing applications (and these will usually be loaded automatically via Collectors).<br />2. Load Code for an Application - Load the code related to the Application into Lattix (e.g. on a PC client)<br />3. Analyse Code of App - Perform analysis in Lattix to determine modules (structure) and their relationships.<br />4. Export Code Analysis - Export an XML file from Lattix that contains modules and their relationships. The project name should be the identified (UUID-State) for the Application.<br />5. Move Code Analysis to Troux space - Make the Lattix XML file accessible from Troux Metaverse by placing the file in the Troux Lattix collection directory.<br />6. Load Code Analysis into Troux - The Lattix XML file placed in the Troux Lattix collection directory will automatically be selected and loaded by the Troux Collector.e into the Troux State, and related to the Application (based on the UUID).<br />7. Examine Application/Modules in Troux Explorer/BP Manager - in Troux Metaverse find the Application and the related Modules (that have been Collected/Loaded from Lattix - via the XML collector) - show pictures of the applications and its modules, lists of modules etc. using Troux Explorer.<br />8. Examine Application/Modules in Architect - in Troux Architect client (connected to the Metaverse/State) e.g. select the Application and get the neighbours from the Metaverse, or explore the Metaverse Tab in Troux Architect to see the Modules of the Application.Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-76925989917616930112007-12-05T13:56:00.001-08:002008-11-27T17:31:37.915-08:00A sensible IT Strategy extract from<div style="text-align: center;"><span style="font-style: italic;">A sensible IT strategy (what I have advocated since 2000)</span><br /></div><br /><span style="font-weight: bold;">Overview</span><br />Some of the key points can be summarised below:<br />- Access: core systems should be accessible from anywhere via internet protocols (and not require VPNs) i.e. Troux (Metaverse/Team server), JIRA, Confluence, Domino etc. We should discriminate against users out of the office.<br />- LAN - should not be used for document storage/repositories (that is the function of the Team rooms and other Domino document databases). And ALL documents of record (contracts, deliverables) should reside in repositories. No new people were to be connected to the LANs after 2000.<br />- Printing - services need to work in all offices (until we can find a remote solution).<br />- NW Access - local offices should just provide effectively ISP access (plus printing).<br />- Devices - all devices connected to local NW should be treated as potentially hostile (i.e. we can't control the devices of all Associates).<br />- Browser - Firefox is browser of choice (was Netscape), IE should only be used when it must be (e.g. some tools unfortunately require it).<br />- Email clients - Thunderbird or Note (i.e. not Outlook - which should not exist on any business owned PCs). SMTP/POP/IMAP services provided by Domino.<br />- IM - AOL/AIM is the IM all users should use. People can use what clients they want to (AIM was the default, but won't connect to other services Cf. GAIM, Trillion).<br />- Office Productivity - we should aim to move away from MS Office (and should avoid purchasing new copies). Especially we should avoid using the new extended document formats.<br />- Drawing tools - the default tool should be OpenOffice stardraw (or Troux Architect) - Visio should not be the default (and we should purchase copies of it). If it is needed for specific projects they should fund this (6the proprietary format is not a suitable format for communication).<br /><br /><span style="font-weight: bold;">Document management</span><br />Notes client (fat client) allows automated replication of documents - it also provides Web access to documents. Documents used frequently should be replicated so that local copies are keep on the client (this significantly reduces the load on the PC). Large documents should typically not be sent in emails they should be referenced i.e. to team room location.<br /><br />Our default document database on Notes is a very primitive one called a team room - its main purpose is to replace the file system e.g. LAN). It is does not have great control for concurrent editing (locking, check-in/check-out) - but in practice this is very seldom an issue. There is an index of team rooms which provides you a simple drill down access to all team rooms (i.e. it is a table of contents for the team rooms).<br /><br /><span style="font-weight: bold;">Model repositories</span><br />Troux team room - should be used to store copies of models that need to be shared or archived.<br /><br /><span style="font-weight: bold;">Other repositories</span><br />JIRA - is used for bug tracking, issues tracking etc.<br />Confluence - is used as a wiki for informal communications (it is NOT where documents or record should reside).<br /><br /><span style="font-weight: bold;">Other newer issues</span><br />- Skype should be used for VoIP (but should not be left running as a default IM).<br />- PDA/Phones - people will use a variety<br />- Wireless - our strategy for these needs revision i.e. external services/standards.<br />- Office formats - we should aim at ODF (not Office XML).<br />- Project - MS Project vs Open project [need to consider]<br /><br /><span style="font-weight: bold;">Special cases</span><br />The above does not apply to 2 special cases - SW developers - who needed what ever their project demands, Accounting. Re Development they will need a range of specialised tools/technologies oriented (IDEs, UML modellers, ER modellers, Databases etc.]Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-42570102593837125872007-10-24T21:29:00.000-07:002007-10-24T21:32:32.932-07:00Gartner's 10 trendsGartner's 10 trends<br />1. Green IT<br />2. Unified communications.<br />3. Business process management (not a technology, just ways to simulate, model and design the processes that run businesses). The evolution of the business process management suite including: model-driven development, content/document management/ collaboration, business intelligence, business rules, business activity monitoring/management, system connectivity and systems management.<br />4. Metadata management. Important as companies integrate data - for instance, customer and product data and warehouse data.<br />5. Virtualization.<br />6. Mashups.<br />7. The Web platform.<br />8. Computing fabric. A server design that is still a work in progress, computing fabric involves treating memory, processors and I/O cards as a pooled resource instead of a fixed arrangement. Blade servers allow you to do some of this pooling with I/O, Claunch said. "Be aware of this, because blades are not the final step," he said.<br />9. Real World Web.<br />10. Social software.<br /><br />RHE's focus:<br />3. Business process management: BPMN (ProActivity etc.), Idiom, Troux<br />4. Metadata management: Troux (Cf. Australian Customs)<br />5. Virtualization: RHEIS<br />6. Mashups:.<br />7. The Web platform.<br />9. Real World Web.<br />10. Social software: HealthPhone was in part oriented at this; HereAndNow alsoMichael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-79184241597939099622007-10-02T17:28:00.000-07:002007-10-02T17:44:12.140-07:00User Interfaces - designEyes are most sensitive to the center of the spectrum (blues/reds must be brighter than greens/yellows), and brightness is mainly determined by R+G. It is harder to detect changes in reds/purples/greens and easier to detect changes in yellows/blue-greens. Trouble discriminating colors affects 9% of people.<br /><br />Avoid:<br /><ul><li>saturated colours (except in small areas to make a point) i.e. prefer pastels for large areas.<br /></li><li>red & green in the periphery (no RG cones)<br /></li><li>pure blue for text, lines, and small shapes</li><li>adjacent colors that differ only in blue or that clash e.g. R/G<br /></li><li>single-color distinctions mixtures of colors should differ in 2 or 3 colors</li><li>using only brightness or colour to indicate differences</li><li>shapes with no boundaries (shapes are detected by finding edges and it is hard to focus on edges defined by colour i.e. with not line</li></ul>Layout<br /><ul><li>time to move the mouse depends only on the relative precision required (i.e. not the the distance). </li></ul>Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-33162857420121309102007-09-27T20:36:00.000-07:002007-09-27T20:38:48.999-07:00SOA Grid<div style="text-align: center; font-style: italic;">(prompted by http://www.soamag.com/I10/0907-1.asp)<br /><br /><div style="text-align: left;">This discusses technologies for scalability e.g. mid-tier caching, load balancing, and high availability through service-level grid enablement for high performance SOAs (SOA Grid) that may help enable enforceable SLAs across service portfolios (WS, messaging, enterprise<br />applications, mainframes)<br /><br />It introduces some interesting architectural issues e.g. remote nodes to cache<br />the programming logic (as well as shared data objects)<br /><br />This leads to a consideration of re-locatable BPEL: i.e. BPEL that dehydrates and then rehydrates itself somewhere else on the grid to execute closer to the service and instance data that it is operating on.<br /><br />It could also lead to Business Rules/Decisions be dealt with in the same way if they were discretely partitioned.<span style="font-style: italic;"><br /></span><br /></div><div style="text-align: left;"><br /></div></div>Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0tag:blogger.com,1999:blog-6601708826898686511.post-54773975239704194292007-09-23T15:28:00.000-07:002007-09-23T16:01:33.579-07:00Software factories and architectural frameworks<div style="text-align: center;">(prompted by "Mass Customizing Solutions" item in Fall 2007 <a href="http://www.methodsandtools.com/">Methods and tools)</a><span style="font-size:130%;"><br /></span></div><span style="font-size:130%;"><br />Introduction</span><br />This item discusses the concept of Software Factories. While it is focused on a very specific sort of development I believe the principles it articulates have much broader application (if the approaches to development and integration are to be improved. It also describes the core thinking underlies the establishment of RHE's AMA (and the idea of instantiatable Development Approaches - DMAs). This lead directly to the need for multi-perspective modelling (e.g. as enable by a metamodeller) to make the management of the resulting knowledge viable.<br /><br />It makes the point that the key intellectual content from a project is not the code. It is information (best held in models, and published in views suited to different audiences) that describes the requirements and design from many viewpoints.<br /><br />Further, in my view, one of the key reasons business analysis does not mature as practice is the absence of a focus on quality (repeatability, consistenty). This is largely because there is not a focus on a consistent set of inter-related business domain viewpoints that can be explicitly captured (i.e. in a model) and people continue to think that the essay style is suited to conveying an sets of essays are useful for managing the knowledge.<br /><br /><span style="font-size:130%;">Architecture frameworks<br /></span>It item discusses Architecture Frameworks (e.g. Zachman):<br /><br /><ul><li><span style="font-weight: bold;">the key intellectual content of a project is not the code</span> - "... interface design and functional factoring constitutes the key intellectual content of software.."</li><li>this<span style="font-weight: bold;"> key intellectual content is captured in these frameworks </span>- "Architectural frameworks capture the intellectual content using view points that identify, separate and interrelate well defined sets of stakeholder concerns"</li><li>the <span style="font-weight: bold;">frameworks have views for a variety of stakeholders</span> (technical and non-technical) - "... stakeholders include business analysts, project managers, developers..."</li><li><span style="font-weight: bold;">viewpoints include business rules, business info, business processes, UI workflow etc.</span> - "Examples of viewpoints include business rules, business events, business information, business processes, user interface workflow and database design. Examples of stakeholder concerns include how business rules are enforced by a given process or how a physical database design supports a logical database design".</li><li><span style="font-weight: bold;">viewpoints need to be able to be nested and adapted</span> (i.e. a metamodeller is useful) - "The software factory schema is an architecture framework ... nesting viewpoints, specific to the solution family...dynamic [e.g.] new viewpoints are added.</li><li><span style="font-weight: bold;">relationships between viewpoints are critical</span> </li><li>viewpoints imply artifact - "a viewpoint ... defines a set of related artifacts..., the activities that act upon the artifacts..."</li><li><span style="font-weight: bold;"> viewpoints/relationships support development</span> - "Relationships between viewpoints are used to support the flow of development..."</li><li><span style="font-weight: bold;">publishing information is key </span>(that should be available from models) - "... publishing information about key processes and artifacts... This metadata is often readily available in the models used by factories."</li><li><span style="font-weight: bold;">publishing information on requirements and design decisions is key -</span> "...Two kinds of information are particularly important ... about requirements, sych as the information captured in feature models ..., about architecture"</li></ul> <span style="font-size:130%;">Benefits</span><br />"The results are generally significant reduction in cost and time to market, significant improvement in the quality attributes, and greater consistency from solution to solution. Risk is also reduced..."<br /><br />"When it is time to maintain or evolve ..., the metadata captured during its development is used to analyse the impact of changes in requirements and technologies.."<br /><br />See other items related in one way or another<br /><a href="http://ea-in-anz.blogspot.com/2007/09/enterprise-data-management.html">Enterprise data management</a><br /><a href="http://ea-in-anz.blogspot.com/2007/08/business-modelling-with-domain-specific.html">Business modelling with domain specific languages<br /></a><a href="http://ea-in-anz.blogspot.com/2007/08/uml-is-not-language-suited-to-most.html">UML not suited to requirements capture</a>Michael Ellyetthttp://www.blogger.com/profile/15756502577563057334noreply@blogger.com0