Distributed Thinking

John Schmidt of Informatica argues that the digital transformation of an organisation is better supported by focussing on the organisation's data, rather than its IT applications.  An application-centric approach structures an organisation's IT by the applications, each of which has a business owner and defined functions.  This works as long as these functions remain separate.  But when more processes are moved online, when the processes become more complex and involve multiple business areas, the emphasis needs to shift away from the individual applications, to the processes and the data that they use. I agree with this point of view.  Software development (of individual programs) moved to this approach a long time ago, primarily with the introduction of object-oriented programming. Basing the structure of programs around the data elements, rather than the processes, made it easier to change the processes.  A data-centric approach to architecture is taking th...

When our Data Protection Officer, Susan Graham, offered to review the draft set of Data Architecture Principles, I was expecting her to comment on legal requirements to minimise access to personal data, or similar concerns.  I wasn't expecting a recommendation to preserve data for centuries, but one of her suggestions addresses exactly that.  In her words, The University has an excellent collection of historic records, from the time of the University's foundation onwards.  This archive is a valuable resource for research, public relations and corporate memory.  Information previously recorded in written records is now being recorded in information systems.  For example, the archive contains a register of every matriculated student from 1627 to 1980.  It would be regrettable if the transition to digital meant that the modern equivalent of these records was not preserved for posterity. So I have modified our principle that projects should understand the d...

We are currently reviewing our catalogue of IT & Library services.   In this, we follow ITIL, the widely used framework for service management.   This has stimulated some discussion about how enterprise architecture can support service management, and also how the two approaches fit together. In my opinion, EA best supports service management by providing context and describing how the various services inter-relate.   An ITIL service catalogue is simply a list of services (in much the same way that an EA interface catalogue is just a list of APIs).   The catalogue does not show how the services fit together, or which business capabilities they support, or which group of users uses each service.   ITIL classifies services along one axis as “business services” or “IT services”, and along another axis as “customer-facing services” or “supporting services”, but these are broad-brush terms and open to interpretation. An architecture diagram can s...

The University's Student Systems team have built a prototype dashboard for our academic schools, to display information about students on the schools' programmes and courses.  The prototype has several tabs, presenting information about applications for programmes, completion results, survey results, demographics, and assessment.  The team consulted with other universities about what works for them, took the best results we found and applied that experience to the needs of our University. The next stage is to turn this into a robust service and this where the architecture team have a role.  We are currently working to define an architecture for the university's BI/MI data, both at the technology level (e.g. a data warehouse) and at the modelling level.  Much of the data used in the prototype has been scraped together using a combination of existing data marts and Excel, with significant effort needed to write complex reports across these multiple sources.  Tha...

This week saw a meeting of the University’s Data Governance Group.  I gave a presentation about enterprise architecture, including my draft principles for data architecture and the need for governance of the data architecture as it evolves. I requested that we produce a list of core data sets, with the data steward identified for each, and a standard process for requesting and recording access to data.  Some of our data stewards already have reasonably mature processes in place, but others do not and the lack of standardisation makes it difficult for people to access the data they need. We had a useful discussion about this and other issues. One key piece of feedback I took away was that my draft principles are focussed on centrally managed datasets, and I also need to consider how locally managed data fits into the architecture. The view of the group is that we need to ensure that this data can be managed without undue overhead.  I think the tools we develop for docu...

Last week I gave a short presentation about my EA work to the Computing Professionals Advisory Group in the College of Science and Engineering (CSE).  Each academic school in the college has one representative in the group, so these meetings are a good way to find out what is happening across the college.  Representatives from IS attend in order to share our news and to hear what issues are being raised in the schools. My contribution on this occasion was to give a brief overview of the plans and intent for the EA practice.  I chose to show some example artefacts from our work and from elsewhere, and to highlight some of the existing catalogues that we could incorporate into the planned architecture repository.  I added an appendix to the slides listing our draft EA Principles, for comment, but I did not talk through those in the meeting. The CSE computing professionals are very keen to have access to download and update data on central systems.  They queri...

I had an “A-ha!” moment when reading a book called Enterprise Architecture as Strategy , published by Harvard Business Review in 2006, which has been recommended to me by several architects working in other universities. The book is indeed very interesting. It looks at the overall operating models of businesses and how the top-performing companies digitise their core processes. The book’s title is slightly confusing because the authors use “Enterprise Architecture” in a rather different way from the main EA frameworks such as TOGAF .  Instead, their book focusses on strategy. If it were written today, a more relevant title might be “Digital Strategy”. There are many useful ideas in this book but the one that most caught my attention was part of the discussion of “architecture maturity” – or what I call “digital maturity”.  The authors present four stages: Business silos Standardised technology Optimised core Business modularity Each stage is described in s...

A Business Model Canvas is a tool for mapping the core functions and capabilities of an organisation.  Compared to the Core Diagrams that I described in an earlier post , the business model canvas attempts to present more aspects of the business, starting with the value proposition – a statement of what the organisation offers to its users (in the business world, to its customers).  It shows the activities and resources, as Core Diagrams do, but also shows user relationships & channels, and also benefits and costs.  I’m not aware of any universities that have used this tool but you can find examples from elsewhere on the web. We are considering business model canvases as a tool for mapping the strategic capabilities of units at the University of Edinburgh.  Phil Taylor, our EA contractor, sketched an outline of what a business model canvas might begin to look like for HR: This is only intended to be suggestive: the real canvas would need to result from in-de...

I very much enjoyed my recent trip to visit the EA teams at three Universities in the American Midwest.   My hosts were generous with their time and gladly shared their knowledge and experience of establishing Enterprise Architecture practices.   I learnt a lot about EA techniques and even more about the soft skills required to establish an EA practice for a large and diverse institution with a limited budget. The topics of our discussions reflected the different priorities that the three institutions have set for their EA teams.   The UM-W team focus on major initiatives rather than try to map the overall space.   They provide EA input to assess which aspects of the current state need most attention and then helping with the transition to the new processes.   This seems to reflect the steer I was given by a Gartner consultant, to show some immediate business outcomes. The other two institutions are taking a more systematic approac...

EA and IT Service Management I completed my USA trip with a visit to the EA team at Miami University.   For the uninitiated (as I was), don't confuse this with the city in Florida: Miami University is in Oxford, Ohio, and takes its name from that of the local Native American tribe. The EA team at Miami is newer than the other teams I visited on this trip.   Still, they have managed to achieve quite a lot in the few years of their existence.   Their CIO has tasked them with mapping the current state of the five domains (Business, Information, Applications, Infrastructure and Security) and they have made good progress with this. Their Enterprise Architect chose to use simple tools for this task.   By using Google sheets to collect data, they could crowd source much of the information, getting input from the staff within each org unit who know the details of which applications are used to deliver which capabilities.   This had a s...

Today I visited the EA team at the University of Michigan in Ann Arbor.    One of the things they showed me was their template for IT services to document their strategic plans.   These are called MESAs, which stands for Michigan Enterprise Strategic Assessment.   The name was adopted to fit the shape of the headline diagram in the template, which looks like this example: Components of the service are placed along the curve to reflect their position in the life-cycle at UMich.   As the deployment of a technology or other service component becomes more mature, it moves along the curve from left to right.   The vertical axis shows when the component is in wide use.   The curve is the same for all services – it is like the Gartner hype curve rather than a graph of specific values.   The icon for each component shows whether a component is recommended or deprecated, with more recent versions of the chart also including...

Yesterday I had an excellent day visiting the architecture team at the University of Wisconsin – Madison (UWM).   The UWM team was created as long ago as 1995, following a major reorganisation of IT in the university, so they have had plenty of time to learn what works and what does not work for UWM. One of their recent successes is a major initiative to transform support for their student advisors.   The advisor role is rather like our personal tutor, guiding students on their choice of courses and helping them when other issues arise.   In fact, one of the outcomes of this architecture work is a web site for UWM students that explains what services the advisors can offer – see https://advising.wisc.edu/ . The problem the team set out to address was hugely complex.   There was no co-ordination or sense of community connecting the advisors in all the different schools, colleges and departments.   Advisors and students had to deal ...

So, what is Enterprise Architecture (EA) and why are we bringing it to the University?   Let me set aside formal definitions and detailed explanations - after all, there is plenty of background information on the web, which you can read should you wish.   Instead, let’s keep this informal and look at what it can do for our university. Essentially, the goal of EA is to link all IT and administrative services together to provide a joined-up, easy-to-use suite of services.   Times have changed from when students dealt with IT systems separately -   logging in to the back-office finance system for one task, the timetabling system for another, teaching systems during the day, and so forth.   Instead, people do everything online, using smartphones or laptops or desktops.   We rarely think about the ”IT” systems underpinning these services, we just do the processes online without really thinking about the IT.   Enterprise Architectur...

Since the beginning of this academic year, I have taken on the full-time role to establish an Enterprise Architecture capability at the University.    For the past few months, I have been working out roles and relationships, principles and processes.   I have given presentations to several groups, first within IS and now moving beyond.   I have recruited an experience contractor to help the University along this new path.   And as the new calendar year begins, we are in the position to start producing results that people can see. A key part of this role is communication – explaining what EA is about, listening to people’s concerns, sharing knowledge of resources new and old, discussing what needs to be done, and disseminating decisions.    I am reviving this blog as one strand of this communication.   Over the years, I have been a pretty poor blogger.   I haven’t always had things to say, and sometimes I have lacked ...

Paul Crowley (@ciphergoth) posted a couple of interesting links on Twitter about the "normalisation of deviance" and organisational culture. The first was about the crash of a light aircraft that happened in Boston in 2014 .  The report concluded that the pilots omitted every safety check they should have performed before take-off, and even when they realised there was a problem they did not abandon the take-off attempt.  As a result, they and their passengers were all killed. What is interesting about the article is the investigation into the culture of the company.  It seems that pilots never performed these safety checks.   The proper process was seen as an annoying waste of time.  We see this in our own industry as well and I was thinking of posting something about the tendency to skip proper sign-offs in a project process. Fortunately, Paul saved me the effort by linking to a much longer blog post by Dan Luu, with the title How Completely Messed Up Prac...

Communication is a key part of every software analyst’s work.  Some of the time we write formal documents such as design specifications or descriptions of coding standards. We write operational documentation for users and for support staff.  We write blog posts that describe our work, and we write comments in our code and e-mails to our colleagues.   We present our ideas in meetings, in formal presentations and informal discussions. So it is important to pay attention to these skills, so that we can communicate more effectively.  There are training courses to help us with the basics.  As with any other skill, we can learn through reading about specific techniques, looking at other people’s work, and reflecting on our own work. (In his book Patterns of Software , Richard Gabriel advocates that reading poetry is a good way to improve our writing skills.  His arguments, on page 149, are worth reading for the virtues they espouse whether you read poetry or...