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

Presentation: Putting IT all together

This is a presentation I gave to an audience of University staff: 

In this seminar, I invite you to consider what the University’s online services would be like, if we worked together to design them from the perspective of the student or member of staff who will use them, instead of designing them around the organisational units that provide them. I’ll start with how the services might appear to that student or member of staff, then work back from there to show what this implies for how we work, how we manage our data, and how we integrate our IT systems. It might even lead to changes in our organisational structure.

Our online services make a vital and valued contribution to the work of our students and staff. I argue that with better integration, more consistent user interfaces, and shared data, this contribution could be significantly enhanced.

This practice is called “Enterprise Architecture”. I’ll describe how it consults multiple organisational units and defines a framework …

Service Excellence, Digital Transformation and Enterprise Architecture

Our University Secretary has sponsored a major review of the University’s administrative processes, coining the banner “Service Excellence”.  The aim is to look at the services we provide to staff and students with a fresh eye, making them more effective, more efficient, and focussed on the user rather than administrative convenience.

Our CIO is sponsoring a similar programme called “Digital Transformation”. This will replace old paper-based processes, starting with the question of what would processes look like if we designed them afresh for the modern connected world.  The aim is to make processes that are more focussed on the user and hence more effective and efficient.

Both of these ambitious programmes will need an effective enterprise architecture, if they are to succeed.  Digital Transformation is intrinsically about using opportunities provided by new technology to improve services and, as such, it requires effective technology services to make data available when needed, to pro…

Not so simple...

A common approach to explaining the benefits of Enterprise Architecture is to draw two diagrams: one that shows a complicated mess of interconnections, and one that shows a nicely layered set of blocks. Something like this one, which came from some consultants:

I've never felt entirely happy with this approach.  Yes, we do want to remove as much of the needless complexity and ad-hoc design that litters the existing architecture.  Yes, we do want to simplify the architecture and make it more consistent and intelligible.  But the simplicity of the block diagram shown here is unobtainable in the vast majority of real enterprises.  We have a mixture of in-house development and different third-party systems, some hosted in-house, some on cloud infrastructure and some accessed as software-as-a-service.  For all the talk of standards, vendors use different authentication systems, different integration systems, and different user interfaces.

So the simple block diagram is, basically, a l…