Can you cost justify Architecture

There is a discussion on Linked In “You can’t Cost Justify Architecture!!! Can you?” “According to Zachman, cost of Architecture should not be scrutinised. It is not an expense but an asset that help in bringing Alignment, integration, change and mass customisation. As an Architect agree with statement but with a business hat on will I agree to that? Probably Continue reading Can you cost justify Architecture

The Zachman framework rolls on

John Zachman will be in Sydney in February delivering pretty much the same old message he wrote about 25 years ago. I got an email today from iCMG asking me if I am “exploring Zachman Certified Enterprise Architect program”. Details are available here: http://live.icmgworld.com/australia/zachman/ My reply was “Thank you for your email, however IMHO, the Zachman framework reached its use-by Continue reading The Zachman framework rolls on

The difference between an architect and a designer.

I draw a distinction between what I think an architect should do – ask questions in both the problem and solution space – and what a designer should do – ask questions only in the solution space. A designer is told what the artifact is and they go away and design it – they don’t question why the artifact is Continue reading The difference between an architect and a designer.

When the PCEHR went wrong

Projects are all about assumptions and decisions In my experience projects go wrong as soon as an invalid assumption or bad decision is made. Once one of these occur, unless it is detected and corrected, the project will fail. The earlier in a project this happens, the greater the impact and the harder it is to detect. In the case Continue reading When the PCEHR went wrong

The PCEHR: The AMA agrees with me.

The AMA’s submission is here: https://ama.com.au/system/files/ama_submission_to_pcehr_review_nov_13.pdf and their press release is here: https://ama.com.au/media/too-much-personal-control-reduces-effectiveness-pcehr My submission was based on the assertion that those developing the PCEHR did not understand the complexity of health information. The AMA has come to the same conclusion, although they have expressed their concerns in the language of health professionals. Here are some selected quotes from the Continue reading The PCEHR: The AMA agrees with me.

PCEHR. How not to build an Information System

You would have thought the most obvious thing to do when building an Information System is to have at least some understanding of the information you want in it. Not the PCEHR. As I explained in my unsolicited submission to the PCEHR review team: My opinion is that, in the case of the PCEHR, the root cause is a simplistic Continue reading PCEHR. How not to build an Information System

PCEHR Review

The PCEHR is being reviewed. In six weeks. Dr David More, who runs the Australian Health IT blog, has been invited to make a submission. David asked for input, and I responded with the following: David, I’m glad to hear that the enquiry is at least prepared to listen to views from the outside. I’ve been looking at the whole Continue reading PCEHR Review

Badly designed contracts always obscure objectives

Delimiter published a piece “Badly designed contracts doom public IT projects to failure” Badly designed contracts doom public IT projects to failure My comment: Badly designed contracts doom public IT projects to failure re “IT contracts often obscure objectives…” I disagree. – IT contracts ALWAYS obscure objectives. IT contracts are written around requirements. Requirements describe (for better or worse) solutions, Continue reading Badly designed contracts always obscure objectives

Overloaded words that can lead to hubris

Words like “requirement”, “problem” and “solution” have been overloaded and hence are misused and abused. For example, differentiating between Requirements and High-level Requirements is meaningless without context. Without context, it might be assumed that they are different places on a linear scale. On the other hand if High-level Requirements refer to the business problem and Requirements refers to the solution,then Continue reading Overloaded words that can lead to hubris

There’s more to problem solving than coming up with an innovative solution

Identifying or developing a solution to a problem is less than half the work required to actually solve the problem. Some solutions are good, some bad, some are cheap, some expensive, some are simple, some complex. What is needed is somebody with leadership who can come up with solutions, but more importantly identify the best solution and put in place Continue reading There’s more to problem solving than coming up with an innovative solution