Skip to main content

Putting IT all together - again

Last Friday I gave a guest lecture to third-year Informatics students on the Software Design and Modelling course.

Professor Stevens, who leads the course, asked me to repeat the presentation that I gave last month to an audience of University staff.  She thought that many of the issues I covered would be relevant to the course, and the topic of improving the online student experience was clearly one that the students could relate to.  It's a long time since I did my own degree but unless times have changed markedly, I suspect that students don't often get to see the issues around integrating many pre-existing systems, rather than building small systems in the lab.

I enjoyed the session.  I don't often get to meet students, so this was a refreshing experience, and we had a good discussion following the presentation. As expected, they confirmed that the online experience currently provided by University systems is "all over the place".

One of the questions was about whether we made much use of UML or other modelling languages in Information Systems.  I explained that we only use UML informally, for example to draw class diagrams or activity diagrams when discussing a design.  We don't use modelling tools as such.  A few years ago, our business analysts did try using BPML to model business processes but that initiative ran out of steam.  I think the problem was that keeping the documentation up to date was too clumsy and time consuming a task.

As I noted in an earlier post, I am looking at Archimate for architecture modelling.  We'll have to see how well this works in practice; currently I am still only experimenting with its use. I think architecture may be a more suitable level at which to use modelling languages, partly because architecture doesn't change quite so quickly as software design, and partly because it is not easy to see the information being presented via other channels (compared with a class structure, for example, which you can view in a developer's programming tool).

In preparation for this talk, I did modify my presentation slightly.  I added a couple of slides that showed "as-is" architectures for a couple of areas, to make concrete the issues that make the delivery of an integrated online experience somewhat less than straightforward.  I talked about the problems of integrating third-party systems, especially where these are not implemented in the most modern technologies.  This gave some context to the rest of the talk which the previous audience would have already understood.

As this audience was of future software designers, I put my discussion of business processes first, where it belongs.  In my earlier presentation, I left business processes to the end, as I didn't want to challenge that audience out of the blocks and maybe put them off listening to the rest of the talk.  In practical terms, of course, we need to start with business processes or we are doomed to fail.

All in all, this was a very enjoyable experience.  If other ISG staff get the opportunity to give a talk to an audience of students, I would definitely recommend it.


Popular posts from this blog

Changing Principles

In EA, architecture principles set a framework for making architectural decisions.  They help to establish a common understanding across different groups of stakeholders, and provide guidance for portfolios and projects.  Michael Durso of the LSE gave a good introduction to the idea in a webinar last week for the UCISA EA community.

Many organisations take the TOGAF architecture principles as a starting point.  These are based on the four architectural domains of TOGAF: business, information/data, applications, technology/infrastructure.  These principles tend to describe what should be done, e.g. re-use applications, buy in software rather than build it, keep data secure.  See for example the principles adopted at Plymouth University and the University of Birmingham.

Recently though, I encountered a different way of looking at principles.  The user experience design community tend to focus more on how we should do things.  E.g. we should start with user needs, use iterative developm…

Why the UCISA Capability Model is useful

What do Universities do?

This may seem a strange question to ask and the answer may seem obvious.  Universities educate students and undertake research.  And perhaps they work with industrial partners and create spin-off companies of their worn.  And they may work with local communities, and affiliation bodies for certain degress, and they definitely report on their activities to government bodies such as HEFCE.  They provide student services and support.  The longeryou think about it, the more things you can think of that a University does.

In business, the things that an organisation does are called "capabilities", which is a slightly strange term.  I think it is linked to the HR idea of a combination of the CAPacity and ABILITY to do a task.  Whatever the name, it is a useful concept.  A capability is more basic than a process: a University may change the way it educates students but as long as it remains a University it will educate them one way or another.

A capability …

A new EA Repository

One of my goals since starting this job two years ago has always been to create a repository for architecture documents.  The idea is to have a central store where people can find information about the University's applications, data sources, business processes, and other architectural information.  This store will make it easier for us to explain our plans, to show the current state of the University's information systems, and to explain what Enterprise Architecture is all about.

It's taken a long time to reach this goal, mainly because we're often had more pressing and immediate work to be done.  The creation of a repository is one of those tasks that is very important but never quite urgent.  So I'm now very happy to say that we are in the process of deploying a repository and modelling tool.

This is the culmination of a careful process to select the most appropriate tool for our needs.  We began by organising several workshops to gather requirements from a rang…