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.

Comments

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 …

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…

2016 has been a good year

So much has happened over the last year with our Enterprise Architecture practice that it's hard to write a succinct summary.  For my day-to-day experience as enterprise architect, the biggest change is that I now have a team to work with.  This time last year, I was in the middle of a 12-month secondment to create the EA practice, working mainly on my own.  Now my post has been made permanent and I have recruited two members of staff to help meet the University's architectural needs.

I have spent a lot of the year meeting people, listening to their concerns and explaining how architecture can help them.  This communication remains vital, the absolute core of what we do and we will continue to meet people in this way.  We also talk to people in other Universities in order to learn from what they are doing and to share our own experience back.  A highlight in this regard was my trip to the USA last January.

Our biggest deliverable for the past year was the design of the data wa…