Gave a talk at the #Webinale on “What Top Management Needs to Know About IT”. Many companies, many CEO treat IT as a black box. In IT is where magic happens and dragons live. In IT are nerds who do thing noone understands. And no sane person wants to understand. IT only needs to work.
This leads to a “digital” IT. It works, works, works until it fails. If you do not understand IT, you cannot understand the risks and performance. What happens in IT might have huge impact on your business continuity and your revenue. Top management needs to better understand IT, IT needs to user better words to talk to CEOs.
My talk aggregates ideas and questions CEOs need to ask and understand and IT needs to tell.
I’m very interested in time to market as I believe time to market is a huge lever. I wrote an eBook on the topic and gave some talks. Recently I gave a talk on time to market at the JAX conferences agile day. The talk went to my satisfaction. It was based on a talk I gave for HackFwd – an excellent incubator for startups. Highly recommended.
After writing the talk I’ve read a book though, Developing Products in Half the Time by Donald G. Reinertsen and included some good points into my JAX talk.
The gist of the talk at JAX was that time to market for development is solved. In the last 15 years the software industry at last found a process that works for software development quite well, after years of trying to adapt conventional engineering processes to software development. If you stick to a process like Kanban or Scrum, you automatically do things that focus on time to market and reduce time to market to a minimum. Nevertheless management often focuses on development, trying to speed things up to get a product or project faster too market. What very few people focus though is before development starts. And that’s where you can improve most.
When I take a look at the company of my wife, eventsofa, a market place for event locations, time to market is usually in the one hour time slot from idea to being live on the site. Risk is high, but impact with only a few users is low, better to be bold and add a fix quickly. For my employer, with millions of users, this way of doing things would be catastrophic.
Last week I gave a talk at the JAX 2012 conference on Java. The topic of the talk was the LMAX architecture using disruptors. The team at the LMAX exchange found out that their problems were not adequately solved by RDBMS systems or SEDA architectures based on queues. The same went for their playing with Actor concurrency. The main trouble comes from not hardware aligned execution and that a lot of CPU power is spent on managing locks and concurrency with queues.
SEDA architectures are a special kind of concurrency problem. A work unit (web request, trade, …) moves through a system of stages and workers do their work on each stage. Reducing the problem space of concurrency, the idea was to do away with the queues and introduce a new data structure: the ring buffer.
I was first introduced to the LMAX architecture in an excellent blog post from Martin Fowler. My talk was heavily influenced by that blog post, but I’ve added a different perspective in it and make it smoother to digest.
Beside the good technical paper, there are blog posts focusing on Cache line padding and lock free publishing to the ring gave me some insights.
The source code for my talk was written by Lars Grindt and can be found on github.