Switching focus at work


Sven Vermeulen Sun 20 September 2015

Since 2010, I was at work responsible for the infrastructure architecture of a couple of technological domains, namely databases and scheduling/workload automation. It brought me in contact with many vendors, many technologies and most importantly, many teams within the organization. The focus domain was challenging, as I had to deal with the strategy on how the organization, which is a financial institution, will deal with databases and scheduling in the long term.

This means looking at the investments related to those domains, implementation details, standards of use, features that we will or will not use, positioning of products and so forth. To do this from an architecture point of view means that I not only had to focus on the details of the technology and understand all their use, but also become a sort-of subject matter expert on those topics. Luckily, I had (well, still have) great teams of DBAs (for the databases) and batch teams (for the scheduling/workload automation) to keep things in the right direction.

I helped them with a (hopefully sufficiently) clear roadmap, investment track, procurement, contract/terms and conditions for use, architectural decisions and positioning and what not. And they helped me with understanding the various components, learn about the best use of these, and of course implement the improvements that we collaboratively put on the roadmap.

Times, they are changing

Last week, I flipped over a page at work. Although I remain an IT architect within the same architecture team, my focus shifts entirely. Instead of a fixed domain, my focus is now more volatile. I leave behind the stability of organizationally anchored technology domains and go forward in a more tense environment.

Instead of looking at just two technology domains, I need to look at all of them, and find the right balance between high flexibility demands (which might not want to use current "standard" offerings) which come up from a very agile context, and the almost non-negotionable requirements that are typical for financial institutions.

The focus is also not primarily technology oriented anymore. I'll be part of an enterprise architecture team with direct business involvement and although my main focus will be on the technology side, it'll also involve information management, business processes and applications.

The end goal is to set up a future-proof architecture in an agile, fast-moving environment (contradictio in terminis ?) which has a main focus in data analytics and information gathering/management. Yes, "big data", but more applied than what some of the vendors try to sell us ;-)

I'm currently finishing off the high-level design and use of a Hadoop platform, and the next focus will be on a possible micro-service architecture using Docker. I've been working on this Hadoop design for a while now (but then it was together with my previous function at work) and given the evolving nature of Hadoop (and the various services that surround it) I'm confident that it will not be the last time I'm looking at it.

Now let me hope I can keep things manageable ;-)