Mick Callan, president of Iasa Ireland
As its inaugural conference opens, the president of Iasa Ireland Mick Callan outlines the thinking behind IT architecture and how it helps to match business goals and IT capability.
There’s a trend in IT towards more rigorous, process-based approaches to delivering services and projects. Is IT architecture part of this movement?
Yes and no is the answer. Process-based approaches are good, structured ways of delivering IT services. Methodologies are formal guidelines. The problem is each organisation is unique and the job of an architect is to tailor these approaches and methodologies to work for the particular instance of that job based on the industry, the strategy of the organisation, or a particular region. They might have different considerations or concerns.
There’s loads of good methodologies. The five pillars of IT architecture are about communicating process improvement, and fitting in to your organisation’s goals, rather than saying ‘let’s pick a methodology’ and that’s the architecture.
So is the bigger trend here really about getting IT and business more closely aligned?
Look at the work of the IVI (Innovation Value Institute) and what they are trying to do, and what architecture is trying to be about is meeting business needs, and tailoring – it’s a good word, I keep on using it – to be ready to meet the business needs and align with the business: how can IT adapt to address those business needs, how can it be more streamlined, structured?
Things I find in work every day might be: is the business looking for a piece of software but they don’t understand the business around that? For example, with file sharing, do you use Dropbox or OneDrive? It’s about IT saying ‘our business need is a file-sharing tool’. IT should be focused on what the business need is, not what the latest tool is. So, you look at it from the perspective of ‘here are the 10 key points that the business requires: this type of security, this type of functionality,’ and it works with our existing products.
IT architecture should cross over between IT and certainly enterprise architecture is more about the business than it is about IT, being able to communicate and articulate what the business needs. Sometimes IT is working well if it’s innocuous. It’s about meeting the business needs and streamlining IT to fit around those in as unconvoluted a way as possible.
The five pillars of IT architecture are business technology strategy, human dynamics, quality attributes, the IT environment, and design. People sometimes put it all in IT environment or design, but human dynamics is a huge part that’s often missed. If you talk to people in the IVI around capability models, they are all tuned around the business needs.
Are the benefits mostly for technology operations, or are there spin-off benefits for the entire organisation?
It’s both. I’d nearly say the emphasis is on the benefits for the organisation by streamlining IT for the enterprise. The IT worker’s job has become more complex. Instead of the old model of large IT departments managing, it’s around saying IT departments in the future will be smaller but they’ll be more highly skilled. The people there will be moving up a level. Instead of being the email server manager, if you put your email in Office 365 in the cloud, and you’re managing it in a higher level, part of it is being managed outside the organisation, so you can do five other jobs as well. (The role) will be more diversified.
Is architecture as a principle better suited to larger IT shops, or can it be applied in SMEs that may not have a sizeable IT team?
I think it works for both, but I think larger organisations need an architecture more, because the larger they are, the more complexity is involved and the more diverse their infrastructure is. IT architecture looks at the big picture around IT. It helps you consolidate and standardise. Through good architectural principles, process and procedures that help converge and simplify or manage the complexities. IT in a big organisation can get very diversified.
Is it about putting IT at a similar level of importance to senior management in other functions?
IT architecture seems to be next step for senior IT people. But it should also be about the IT person providing a service that meets the business needs. Everything comes back to helping the business, and that’s where it needs to be focused on. It’s the overarching point, and a big part is communicating that, and how important enterprise solutions are for the organisation. And communication is a two-way street.
Communication isn’t always something IT professionals have been renowned for. Do they need to become better communicators?
Absolutely. An IT architect has to be a good communicator. You need to be able to bring people along with you, to have good stakeholder management skills – which can be internal management in the organisation, and people who need to see the benefit of what you’re proposing and to give you leeway to build the structures for long-term benefit – so that every IT project and every piece of IT infrastructure is structured to meet a business need.
Can communication be learned as a skill, or does it take someone coming in from outside IT – which we’ve seen happening with some CIOs?
We’re an umbrella for all IT architects. There’s the business architect – who looks at IT strategy, they have to be good communicators and maybe they have less hands-on knowledge of how servers operate or coding standards. Then you have the solution architect who is more into network designs, or what coding tools are being used.
Then you have the data architect who is concerned with how data is managed and owned across the organisation, and then you have infrastructure architects who are concerned with what network connections we’re using, and so on.
Over all of those is the enterprise architect who liaises with those four domains and is a buffer zone between business and IT. The enterprise architect should be very business focused and should sit outside the IT function, in many cases. The four domains under that would be the IT function.
What you’re saying is that the architectural mindset can be applied at any level of IT?
Information technology can be done at a very granular level. Where IT architecture comes in is, it sits between that and says you can’t do things in isolation, there has to be a structure. It doesn’t matter what methodology you want to use, but you tailor your processes and procedures to create an abstracted middle layer.
It’s not about some guy in IT saying ‘there’s a new device, let’s use that’. It’s about saying what tools do they need to use in a cost-effective way across an organisation? It’s about thinking how IT can meet needs without bringing brand loyalty into it.
If you do it right, it should bring down costs in the long term, because you should ultimately be able to consolidate the tools that you’re using. That means less vendor management. What it comes down to at the end of the day is efficient, well-managed IT. Because traditionally, IT has been seen as such a cost to the business.
Can you give examples from your own career of where you used IT architecture to get a better outcome?
I do a lot of work around IT strategy, and for example, what’s our approach to BYOD (bring your own device) or cloud computing? People are very scared for what it means for their jobs in IT. But if it takes the pressure off people, it gets more throughput and arguably saves money.
I sometimes get put out there as an advocate of cloud. I’m not that. I see it as an extra tool in the toolbox to be considered. If it’s suitable, and clear benefits can be applied, use it. If they can’t be identified, don’t use it. It’s just saying ‘consider it’.
IT has to evolve and change, and IT always has. You move from mainframes to client/server and now you have virtualisation. If you’re scared that you will be moved, well, you need to move, or you’re in the wrong industry. In five years’ time something else will come along.
Your conference today will cover the future of the IT department. Right now we’ve got the traditional computing model turned on its head; users are now asking to use their own devices and bringing their own apps instead of the IT department maintaining control. Is IT architecture and ideas about structure incompatible with a trend like this?
It’s not incompatible. Again, it comes down to what suits at an organisational level. The big debate about BYOD is whether companies want to be restrictive or permissive. It depends on the organisation and the data it works with; certain organisation have less sensitive data, have a younger workforce and are very communicative, where a BYOD policy would be permissible. In an organisation such as EirGrid, where I work, there’s sensitive information involved, it’s highly technical and it’s not something you want to have a loose structure around.
It’s about enabling working in a mobile environment but ensuring the devices and the data are secure. Maybe you tie down to tools that meet your requirements. Again, it’s down to tailoring for your organisation.
There’s always this tradeoff between enablement and security. It’s about creating that balance to be as secure as you need to be and enabling as much as you can. Instead of saying ‘no you can’t do this’, you tell them in a positive way ‘if you use this device, you will be able to do this, this and this’ …
It’s a difficult balance to get to, but that’s the ultimate goal of an IT architecture. It’s to create balance, to meet business needs with security requirements and managed costs.
