Tag Archives: technology

Part 1: Fresh meat and learning about user involvement

 

 

Sara Henderson
Graduate Intern (Student Champion),
Student Systems Project (Corporate Information and Computer Services)
University of Sheffield

 

 

UCISA SSG17: Reflections from a bursary scheme winner

I should start by introducing myself.  I’m Sara and I work as Student Engagement Officer on a major business change project at the University of Sheffield.  I began in January on the University’s Graduate Internship Scheme, before being extended in my role.  A colleague encouraged me to apply to UCISA’s bursary scheme as a junior member of staff, so that I did.

I am interested in technology but motivated by people, so SSG17 presented the perfect opportunity to learn from others in the sector and gain a wider perspective on the work I’m doing.  Now that’s out of the way, we can get to the good stuff.  I present to you my diary (of sorts) from the conference, showcasing some of my thoughts and favourite moments.

Day 1

11:30am

Fuelled by coffee and adrenaline, I find myself in the conference exhibition space, perusing the exhibition but avoiding eye contact.  I glance around the room to see pockets of conversation forming; for some this is an opportunity to catch up with old friends and colleagues, whereas the rest of us are fresh meat.

13:10pm

Neil Morris from the University of Leeds captures the delegates’ imagination with his presentation ‘Reimagining Traditional Higher Education in the Digital Age’ , focused on how to embed technology-enhanced learning in partnership with students.  “We don’t involve students in projects, we don’t seek their feedback in ways they are interested in giving it, or make use of their intelligence and creativity”.

Neil’s talk affirms why I wanted to come to this conference, challenging the status so often assigned to students – as being passive receivers of knowledge and services, rather than intelligent consumers.  We ought to be involving students in project work, fundamentally and authentically.

15:50pm

Room 101 proves a fantastic way to end the first day, with an all-female panel and some very funny moments.  Did someone say Apple Genius Bar?

11:20am

The day kicks off to an unnerving start when I find out that the panel I am shortly appearing on is one of the most popular sessions of the conference.  To find out more about my experience, head over to my second post – ‘Part 2: Not in the IT crowd (and that can be a good thing)’.

12:20pm

Now for perhaps my favourite talk of the conference: ‘Technophobe Testing’ by Francesca Spencer (Leeds Beckett University).  The basic premise is that in IT of all places, we ought to be involving technophobes, because they can actually be a help rather than a hindrance to our work.  Francesca had the brainwave of recruiting some self-confessed technophobes, and observing their use of AV equipment in a judgement-free zone to determine how to make it more user-friendly.  We need to embed our users in the process of implementing technology (before it’s too late).

Day 3

9:00am

I’d be lying if I said I didn’t have to climb down from my pedestal during breakfast, on what is affectionately known as “fuzzy Friday”. Unlike some of the conference-goers making a beeline for a fry-up, I opted to for a sensible night in after a case of conference-fatigue…

12:30pm

Paul Boag closes SSG17 by informing us ‘How to Create a User Experience Revolution’ .  His insistence that “if you don’t speak to your users once every six weeks, you don’t get to be a stakeholder in a project” certainly rung true, and he comfortably drew together some key themes from the conference, about collaborative working, establishing shared values and cultural change.

So there we have it – my experience in a nutshell.  Thank you to UCISA for having me, and if you want to hear more from me, head over to my second post ‘Part 2: Not in the IT crowd (and that can be a good thing)’, or follow me on LinkedIn:

(Presentations and video streaming available at the conference website)

Post-conference reflections from a bursary award winner

Allister-Homes-Profile-pic---small

 

 

Allister Homes
Senior Systems Architect
University of Lincoln

Gartner EA Summit – a week on

It’s been a week since I got back from the Gartner EA Summit in London, so I thought I would provide some reflections on the event. These are purely my opinions, and other people may well have a different take. If you’d like to see more of the detail of the event, have a look at my previous two posts (day 1 and day 2).

I think the focus was on larger organisations, and there was often an unvoiced assumption that there were significant numbers of architects and developers within the organisation (compared with what a typical university would have). It wasn’t unusual for suggestions to be made along the lines of ‘when you get back, why not assemble a small team of 5 people to go and investigate X, Y and Z’; having the capacity to do that sort of thing at short-notice sounds like quite a luxury.

Like many large conferences the non-keynote sessions were categorised into tracks, and at this summit they were A: Delivering Business Outcomes, B: Leveraging and Leading Practices in EA and C: Architecting the Digital Business. Rather than stick to a particular track I moved between them, going to the sessions that sounded most relevant to my work, organisation and sector. Sessions that were in the same stream contained common threads, as you would expect, and – in a couple of cases – some repetition.

I think directly applying what I learnt to day-to-day EA in HE will be more challenging than I initially thought it would be. This is because many of the sessions I attended were future-based (what changes to consider in the coming years) and either very strategic or focussed on large-scale IT development approaches (such as changing paradigms to one of micro-services and web-scale IT). It’s not an event that I would suggest attending every year, but would perhaps provide a useful background of EA direction every two or three years.

Being candid, the networking was not as useful as I had hoped. Conversations seemed to be mostly between people who already knew each other, which of course is only natural for any of us. I tried starting conversations with a number of attendees during breaks, but found that although everyone would give succinct answers to opening questions along the lines of where they were from, what they thought of the previous session, and so on, I couldn’t get a conversation going. I thought perhaps it was just me for a while, but then noticed the same thing happening to other people making such attempts too (which was something of a relief!).

As I mentioned, I selected the sessions that sounded most relevant rather than what sounded most intriguing or interesting from a personal rather than professional point of view – e.g. I went to ‘Business-Outcome-Driven Application Strategy’ rather than ‘Smart Machine Disruptions Will Dominate This Decade’, which ran at the same time. In hindsight the more extravagant sounding sessions may have contained relevant information too and perhaps provided some alternative ways of thinking about things.

The above may sound a little negative but that’s not my intention. It was an interesting and useful conference to attend, and I’m just trying to provide an honest and balanced opinion. I think the main topics and take-away points, based on the sessions I attended, in no particular order, were:

  • The Internet of Things (IoT) will become more important and will need more consideration, including by considering Things in the business domain, not just information systems or infrastructure domains. Also, computing everywhere is becoming the norm, but try to think people first rather than mobile devices.
  • Organisations need to operate in the digital world and interact digitally. Expect significant changes over the next 5-10 years, not just small increments – things you cannot yet imagine.
  • Large-scale application architecture is shifting towards an app and service approach, and a more extreme approach to Service Oriented Architecture (SOA). For new-style web-scale IT (but not enterprise scale core systems so far) there is a shift away from large systems and databases, including moving away from 3NF.
  • Software defined applications and infrastructure should be expected for networks, security, and other core elements to replace less flexible and less responsive infrastructure.
  • Business architecture is a critical element of EA (but we all know this already, don’t we?)
  • Attention needs to be paid to enabling technology to respond to business moments. It is often impossible to predict these business moments, so the approach must be to architect for agility instead.
  • Use the wisdom of the crowd: consider taking advantage of opportunities to crowd source solutions to problems, whether in the business or information systems domains.
  • Make good use of models, roadmaps, stories and personas to engage people, explore with them and explain to them. Use the right tools and techniques for the people in question.
  • Cloud offerings are becoming more complex, so architects need to understand what vendors are really offering, not just the fog and hype. Reasons for moving to cloud are not just cost (and in fact there is often no cost saving) – instead the drivers tend to be technology agility, business agility, offloading responsibilities, and advantages of security and scale. Most organisations are likely to use a hybrid of cloud services.

 

UCISA has an Enterprise Architecture community of practice which may be of interest.

Enterprise Architecture Trends and Strategies

Allister-Homes-Profile-pic---small

 

 

Allister Homes
Senior Systems Architect
University of Lincoln

Gartner EA Summit Day 2

I’ll take the same approach as the blog post for day 1, summarising the sessions I attended.

Top 10 strategic technology trends for 2015

top 10

I thought this session brought together some of yesterday’s themes quite nicely – I’m not sure if that’s how it was intended or whether it was a coincidence (or even just my interpretation), but that’s how it came across to me.

First of all the presenter explained the traits that the Vanguard Enterprise Architect – Gartner’s term for the architect of tomorrow – will need to have:

  • Futurist, trend spotter
  • Business visionary
  • Technology analyst
  • Strategist (social connector)
  • Educator, communicator
  • Vendor watcher
  • Leader, collaborator
  • Evangelist, catalyst
  • Salesman

We were told that if you see trends in a spectrum, the enterprise architect should consider adopting trends, and how they can help the organisation, during their growth phase – after the emerging phase (when disruption is uncertain) and before they become mainstream (when the disruption is happening or has happened).

The top strategic trends Gartner identified as being of greatest important to EA over the coming years are:

  • Merging Real World and Virtual World
    • 1 – Computing everywhere (think mobile people instead of mobile devices)
    • 2 – Internet of Things
    • 3 – 3D printing
  • Intelligence everywhere
    • 4 – Advanced, pervasive and invisible analytics
    • 5 – Context-rich systems
    • 6 – Smart machines
  • New IT reality emerges
    • 7 – Cloud/client computing
    • 8 – Software-defined application and infrastructure
    • 9 – Web-scale IT (our IT world will look more like Google)
    • 10 – Risk-based security and self-protection

Business outcome driven application strategy
The focus of this session was bimodal application strategies, particularly the use of mode 2. Most IT departments are generally seen as good at identifying savings and efficiencies that an organisation can make, but not necessarily as good at supporting new revenue opportunities and taking advantage of new opportunities. Organisations need to take advantage of business moments – that is, opportunities that arise suddenly and are transient – and if the IT department is not good at responding to those opportunities with the business then they will become marginalised and bypassed. We heard how business moments are human-centric, transient, ad-hoc and blur the physical and digital boundaries. The difficulty for enterprise architects is that it is hard to plan the target state for these business moments when we have no idea what the state will look like until the transient opportunity arises. Instead, we have to design the architecture to be able to respond to opportunities rapidly as they arise.

In bimodal IT, mode 1 is the more traditional way of doing things, is consistent, has steady governance controls and does things ‘the right way’; mode 2 on the other hand has no simple path, is flexible and adaptive. Mode 3 looks more chaotic but it doesn’t have to be. Mode 1 might use a waterfall methodology (but might use Agile) whereas mode 2 can only succeed with Agile methodologies.

It was suggested that when starting out with a bimodal approach, we should first pick a specific project or projects to experiment with. Use agile approaches, devops, create an innovation lab and use small vendors. Then, as competence with mode 2 and a more unstructured world grows, mode 2 can start to be applied in more situations. There are significant differences in characteristics between mode 1 and mode 2 approaches, including funding arrangements, which are less predictable but can be less risky with mode 2. In an Agile project it will be known much earlier whether a project is likely to fail than would be the case in a waterfall project (called failing fast), and much less of the budget would have been spent, meaning the financial risk can be lower. Organisations will probably always have some mode 1, but a bimodal approach will start to displace it to some extent.

This session was presented by the same person who presented Application Architecture for Digital Business yesterday, and the information about app and service style application architecture from that session was repeated in this one. It was suggested that the likes of Nginx and in-memory computing are used for scale and performance. There was also a comment that, for integration, don’t assume the ESB is centre of universe. It is still good for core systems, but gateways (e.g. with APIs) can be faster and easier for mode 2 applications.

Orchestrating Ideation: Creating Breakthrough Innovation Opportunities
The ‘nuts and bolts to drive innovation’ were presented in this session, which concentrated on thoughts for an innovation pipeline. Innovation in many large businesses used to be driven by a small group, perhaps a dedicated Research and Development team. Businesses need to, and are, changing this approach now, partly because it is increasingly possible for someone with a good idea to simply go out and build it with tools at their disposal (cloud-based services in the case of IT tools) without the involvement of specialist teams in the organisation and without any kind of governance or approval. The change of approach needs to move from the likes of R&D teams to the wisdom and diversity of the crowd, and from managing innovation to orchestrating, engaging and motivating the right set of people and guiding them through an innovation pipeline.

Gartner has come up with a way of categorising problems according to their nature and applying different methods to crowd-source solutions depending on that categorisation.

pic 2

Problems can be categorised as complicated (e.g. putting a man on the moon in 10 years), complex (e.g. climate change) or chaotic (e.g. traffic movement). For each categorisation there are different knowledge scopes, and also different approaches:

  • Analysis for complicated, breaking down the problem into smaller pieces
  • Synthesis for complex, aiming for the best outcome to a problem without a way of necessarily knowing if it is ‘solved’ (see yesterday’s blog post for a session that covered analysis vs synthesis)
  • Selection for chaotic, where the whole problem can’t necessarily be solved but solutions can be selected to solve incremental parts of it.

Stakeholders will also vary according to the problem type. This is all much easier to explain using a series of Gartner’s slides, but I don’t think I can reproduce that much copyright material without falling the wrong side of the rules.

When it comes to the type of crowd used to solve the different categories of problems, complicated problems are best solved with specialist teams, e.g. the DARPA robotics challenge; complex problems are solved best with community co-creation, starting with a goal rather than a problem and then selecting the best option, e.g. the way the city of Porto Alegre involves citizens in setting the use of the discretionary budget; and chaotic problems are best solved using the largest possible target audience and giving the community a broad space to get many different ideas rather than setting a specific goal, and then working through filters of selection, development and final launch, e.g. the Department of Work and Pensions’ staff ideas scheme.

All of this needs to be done by putting rules and recognition/reward around a process. Participants are motivated from having autonomy (being part of the change), mastery (developing skills) and purpose (having meaningful contribution). A pipeline provides creative constraints to encourage creativity, because if there are no boundaries or guidance at all it is harder to think of something to be creative with, and organisations should put in place a way of managing innovation portfolios to make the best of crowd sourced ideas.

Digital Business Architecture Fuels Digital Business
At the very beginning of this session, it was emphasised that if you are not doing business architecture you are not doing EA – you’re doing EITA (Enterprise IT Architecture) instead. It was also emphasised that business architects must be part of the EA team, and even if there are reasons why the reporting lines for personnel are different it is still important for business architects to sit with and work with the rest of the EA team in a virtual team. Gartner estimates that by 2017 60% of Global 1000 organisations will execute at least one revolutionary and unimaginable business transformation effort, and if business architects are not an intrinsic part of the EA team then the rest of the architecture will not be able to respond properly to these transformations.

pic 3

My interpretation of this session was that much of it was about what should already be taking place in the business domain of EA, with elements of how to take it a little further. One interesting point is that organisations, people and things (think Internet of Things) will all be equal peers when it comes to digital business designs in future. I thought other aspects, such as how business architects should work on business strategy and goals, fill the gap between strategy and execution, and so on, were what has been suggested for a long time. Business moments were talked about again (see earlier in the day) and likened to lightning strikes of opportunity. The suggestion was made that to gain an advantage and be able to respond more quickly than competitors, business modelling should not stop at the boundary of the organisation; instead, also model the business domain of partners, competitors and customers.

Finally, the presenter urged IT and EA departments NOT to think of, or refer to, the rest of the organisation as customers, because doing so makes IT and EA subservient to the rest of the organisation. IT is intrinsic to most modern organisations and crucial to their futures, and department staff should be thought of as peers.

Three Roadmaps to Guide and Drive Change in Your Organisation
As the title suggests, this session was about roadmaps. The first point was that not every roadmap suits every stakeholder – it’s no good giving a tube map to someone getting the bus. In some cases a particular roadmap might only be relevant to a few technical staff, and there is nothing wrong with that because those people need that roadmap, but it would be a mistake to give the same one to board members. The definition of a roadmap provided by the presenter is that it is graphical, illustrates milestones and deliverables, and shows transition from current to future over specified time. Time is the primary dimension, but additional influencing factors may be shown, and the level of abstraction must be appropriate to the audience and purpose. That leads to the first piece of critical information when creating a roadmap – who and what is it for? By understanding that, an appropriate roadmap can be developed that is fit for the people and for the purpose for which it is being created.

pic 4

At this point similar emphasis to that of the previous session was made about the importance of not thinking of the IT department as separate to the rest of the organisation. You wouldn’t typically talk of the finance department and its relationship to the business, for example, so don’t do it with the IT department.

It was also suggested that staff from within the organisation are sought out for how they can help with roadmaps – many organisations have a marketing department with staff who spend much of their time making things look as appealing as possible, so ask if they can help do the same with your roadmaps for example.

A topology of roadmaps was presented covering quadrants of operational planning, operational execution, strategic planning and strategic execution. Roadmaps tend to fit towards the strategic rather than tactical axis, but lifecycle roadmaps cover some of each because they cover the full life cycle of a capability or system over time. Evolution roadmaps show a specific target state and what components are introduced or removed to support the required business outcomes. An enterprise roadmap shows current and planned strategic change at a contextual level, again including the time dimension. It tracks high level business outcomes linked to KPIs, and indicates change across the whole enterprise rather than just one programme or area of it.