I recently had a discussion with a colleague about what the real purpose of architecture documentation is. The simple answer of “documenting the architecture” seems unsatisfactory to me – “what is the point in that?” I think. My response to him was that architecture documents are for recording (and communicating) architectural decisions.
In other posts I’ve described the conceptual components for an end user computing environment and the scenarios (or use cases) for use of end user computing. However, the enterprise end user device or ecosystem doesn’t stand on its own – it sits within a complex environment of corporate (IT) services. When looking at the end user computing space it is important to understand which of the other, more general, IT infrastructural services are involved in delivering or supporting it. Understanding the inter-relationships here can make our design of the end user computing environment more complete.
A while ago I posted a desktop conceptual architecture. Since then I have been doing a lot more thinking about the desktop and its overall place in the IT and business environment. So, firstly I have changed the title to an end user computing conceptual architecture (a bit more of a mouthful, but more accurate I believe). Secondly, I’ve changed my picture slightly to include security and security management in it. These were elements that I had overlooked in my original thinking.
This is the third in a series of posts about end user computing and desktop architectures. In a previous post I discussed a preliminary conceptual architecture for end user computing. What I want to look at in this post is ways of understanding how people work (in relation to end user computing) that could inform our understanding of what our architecture needs to address and therefore ultimately look like. In order to create the right end user computing architecture you need to understand the needs that the people in your enterprise have for end user computing. And, in order to understand the needs of your people for end user computing you need to have some sort of way of looking at different ways they have of interacting with their computing environment and tool-sets. The approach I am taking here is to outline a set of “use cases” that describe scenarios where people interact with the end user computing environment in different ways. Once we have these use cases we can then analyse our user community to see which combinations of use cases we need to support. From there we might take a range of approaches. We might offer a range of services to our users. We might segment our user base and then attempt to create solutions (or sets of solutions) that meet the needs of each segment. We might (if our people’s needs are homogeneous enough) create one solution for everyone. But the starting point for any solution must be to understand the fundamental needs you have to meet.
This is the second in a series of posts about the desktop. In the first post I described a conceptual architecture of the desktop, or end user computing environment. In that first post I used the term desktop, since then I have had a change of heart, or at least of terminology. I’ve been thinking about the wider computing environment that people use and encounter in their daily working lives and I see that it is both much bigger than what we traditionally call the desktop, and that it is all connected – part of a multi-dimensional spectrum of ways of interacting with devices and software and ways of managing those devices and software. We need to understand the commonalities between the way that people use mobile phones, traditional desktop PCs, virtual desktops, ruggedised devices, special purpose devices, and their applications. For this reason I’ve decided that I won’t use the term “desktop”, and will instead use the clumsier term “end user computing”. While not so elegant, it does seem to me to better describe what I am trying to talk about, and is at least better than (or less ambiguous than) any other alternative I’ve come across.
I recently read another thought-provoking article from Anna Mar (aka @simplicableanna) entitled “How to Explain Enterprise Architecture to Your Grandmother“. It contains good advice: “it is a useful exercise to think-out an explanation that doesn’t rely on specialized terms” – especially when you are thinking about what you do for a living! So, how does Anna respond to this challenge? With a tried and true metaphor for Enterprise Architecture:
read more »
Talking and listening to Jim Harris of OCDQ Blog has got me thinking about data management. Specifically I’m thinking about the challenges facing data management in the New Zealand government sector – where I currently work. Initially when I started here, and saw some issues relating to data management, I thought: “yep, I’ve seen this before – the issues and the answers are the same as in the private sector.” Now that I have been working here a bit longer, I realise that this is only half right, that there are some issues that are specific to government (or the New Zealand government) and that some solutions common in the private sector cannot be straightforwardly applied here either.
One of the significant challenges facing data management in government is navigating the restrictions and constraints introduced by privacy legislation. Why does this matter and how does it impact data management? Well, to take just one example: you can’t create a single view of a customer (or citizen) if the interpretation of privacy law is that you aren’t allowed to match pieces of information about the same person if they are obtained for different purposes. I thought I’d write a series of short posts on this topic, starting with this one on why privacy is a bigger issue for government agencies than it is for the private sector.
I have recently discovered the podcast on data quality (and related matters) called OCDQ Radio. It is part of the OCDQ Blog “empire” (term used advisedly!) run by Jim Harris. What does “OCDQ” stand for? Well: Obsessive-Compulsive Data Quality, which pretty well describes Jim and his attitude towards data quality and other things data related. OCDQ Radio is exactly what I like in an enterprise IT (for want of a better label) podcast. The podcasts are in-depth examinations of particular topics related to data quality (the episodes on identity matching and master data management were particularly good). They give you a decent introduction to a topic, and then follow that up with a closer examination of specific issues in that area. If you are interested in data quality in the enterprise, and in understanding the different technologies and methods for improving it, then I would recommend you listen to this podcast.
OCDQ Radio on iTunes.
If you are interested in Enterprise IT I recommend the IT Pro Show podcast. I find podcasts really useful and interesting: they make otherwise boring activities like exercise or travelling to work an opportunity to learn something. I have , however, struggled to find any that are relevant to my professional interests. I have looked hard for enterprise architecture or enterprise IT podcasts but found very few promising ones. Most of those have either been vendor material or are long out of date. The IT Pro Show is a weekly podcast where the three brothers John, Mike and Tom have an informal look at Enterprise IT. Each show has regular segments such as upcoming conferences, books, corporate news and key topics of interest in Enterprise IT. The most recent podcast had a great discussion on desktop virtualisation. You can also subscribe to the IT Pro Show through iTunes.
If you know of any other good enterprise IT podcasts, why not let me know by commenting below?