Preamble:
In 1991, Dr Chris Horn, Dr Sean Baker and Annrai O’Toole each chipped in £1,000 Irish Punts to bootstrap a business called Iona Technologies. There was no bank loan, no cash flow, and no Enterprise Ireland. I doubt anyone would have put up the money if they had even asked at the time.
They took an educated punt, building on the back of years of academic/industry R&D into distributed systems and programming, supported in part by EU Espirit research programmes.
One of the running jokes in Iona’s newsletter iContact was the management teams’ 3-year search in the wilderness for a business model, but the truth was, that they always had their eyes on the prize and were constantly tweaking the business model to the situation and demands of the market of the day. The way Iona ‘organised’ was the key. It was a young Irish company with a distinctly Irish culture. Small nimble close knit teams, everyone knew everyone and no one let formality get in the way of celebrating success or getting to the heart of a problem. As a place to work it was hectic, razor sharp, direct and fun.
 |
| figure 1. Leasing Pembroke Street from Crampton's (credit McCarthy 1995) |
Iona’s product Orbix brought Iona success but Orbix was also successful because of the way the company was organised and the way it (the software) `organised' or structured its customers. Professional services (PS), delivering C++ and object oriented programming training to large multinationals like ICL brought in revenue. The profits from services went straight back into product development but more importantly, the learning that Iona acquired on customer sites was transformed into features in Orbix. The the need for training in Orbix itself in turn drove demand for more services and contracts to integrate Orbix with client systems. Iona excelled in understanding the process of designing and deploy mission critical cross-platform distributed systems. This knowledge in turn was transformed into even better features and functionality for Orbix and a growing list of adapters, services, language mappings and platforms.
Iona had an instinct for the business and economics of digital networks a decade before anyone else. They tuned the business model to the market. In a way the business model was built into the architecture of the product, linking software, linking firms, linking markets and people. The business model was evident in how they bootstrapped the market for their product. But the business model wasn’t Iona; Iona was the people. The social banter at coffee stations, Wine and Cheese events, gatherings under marquee in Fitzwilliam Square, the Christmas party at Howth Castle, catching up after work in McHaffey’s, Kehoe’s, Slattery’s or Tonor’s. Welcoming someone back from a sales or service job in Seattle, politicking Standards at the OMG, attending JavaOne or Iona World. Networking is an intrinsically human thing and something the Irish excel at.
 |
| figure 2. Toners on Baggot St - the snug (2015) |
The period 1999 - 2001
The resources available for R&D are competing with customer demands on current products. A decision is needed to address the problem but no one agrees on the solution.
Product Development Culture
Growth is good and profits are better but they come at a cost. The cost for Iona’s Dublin headquarters was having to move office each year. From Westland Row to Pierce Street, to Percy Place, to Pembroke Street Lower (figure 1), then the big split from Pembroke Street to St Stephen's Green. Stephen's Green would have been nice except that Product Development and Customer Engineering were housed in an old office block tucked behind a Georgian town house while the corporate functions had modern air-conditioned comfort half a mile away on Pembroke Street. But this was only temporary, a year-long hiatus. Iona would be the anchor tenant in a brand new tower block on Shelbourne Road. The "Iona Technologies Building." This last big move started in 1999 but the things were changing in other ways. The atmosphere of the company was evolving with each office move and each new employee.
The company had been famous for its 'everyone knows everyone else' feel and exciting work culture. However a sense of 'community lost' was increasingly apparent in conversation. The demise of the traditional wine-and-cheese on the last day of the month was a sign of this gradual change.
“What’s happening to the monthly ‘wine n cheese’? First it’s reduced to quarterly, and then half yearly... we need it for morale!” [engineer]
“The Iona wine and cheese was important, we need these opportunities to mix, to build spirit. Stop cancelling them!” [anon]
Structure and Organisation
The company is organised around three main development centres; head office in Dublin, the US headquarters in Waltham Massachusetts (aka Boston), and the Asia/Pac office in Perth, Australia. Internally the company has a hierarchical structure with product development (PD) teams organised into 24 product lines delivering to 3 main operating environments (Solaris, HPUX and Windows) and over 20 version variations on other platforms (Digital VMS, AS/400, MVS, SCO/Unix, QNX and others).
The product managers develop concepts and business cases for new products that are then assigned to an engineering team for development. The Iona PD Process has four main stages: Planning, developing, testing & QA, and Launching. The project life cycle provides procedures for the development of products, covering the whole development process from beginning to end.
"Product Development is team-oriented. Teams have strong software engineering capabilities but also have product management, project management, customer service, business and other skills represented. Each team has significant autonomy and discretion on what products it develops, and has responsibility to describe why, when how and by whom the products will be built, licensed etc. Teams are ultimately responsible for product success, measured in market share and revenues." [The dev team guide]
Customer Engineering (CE) is the support organisation and is also organised by product line. This allows dedicated customer support engineers to develop deep technical product knowledge. All support engineers are expected to also be able to support core Orbix. This is useful to balance support capacity if customer demands peak on different product lines. Support engineers are also seconded to engineering teams to facilitate the mutual transfer of product knowledge and customer context between CE and PD.
Orbix and ART
The company has experienced continuous growth in market share, revenues and profit in recent years. However, rapid success has led to rapid growth in headcount. They have been hiring `as many people as they can get' to develop, support and maintain the products.
Orbix is the company’s 'cash cow', revenue-rich, mature products that 'only' require maintenance. Cash cows provide a steady income from license fees generated both by new customers, and renewed annual service or support fees from existing customers. In Iona’s case, sales of large site licenses with annual support contracts are a lucrative revenue stream.
Orbix is the worlds most deployed distributed object request broker; a fully featured product architecture used to connect object databases, messaging and transaction systems, media streaming, and real-time operating systems to the internet. The Orbix product architecture has grown around orbixd (as in a Unix system daemon process). The orbixd is simply an ORB (object request broker) for connecting code written for a variety of programming language/compiler combinations. Language mappings for ADA and PL/I were even developed for the US defence sector and the IBM mainframe environment respectively. The Orbix daemon and libraries run on Unix, Windows and other more niche operating system environments such as VMS, Vxworks, even MacOS. There is also talk of Orbix Nano for embedded chips.
As the Orbix family of products has grown so too have the numbers of people developing, supporting and maintaining them. This has led to problems for management and interdivisional communication. In just over three years the company had grown from 10 to nearly 300; and over the following three years to over 1,000. The Orbix dev team alone grew from 3 to 50 programmers plus 30 or 40 more in support and services.
Orbix is the focus of everyone in professional services and product management. Yet the cost of supporting legacy Orbix is eating into the company’s profit margins. Industry too is seeking to move beyond the limitations of the object request brokers and is pivoting towards new technologies, paradigms like XML based application servers, web services, service oriented architectures and enterprise Java.
A skunkworks project codenamed ART (Adaptive Runtime Technology) was started in 1996. ART development was based in Boston. ART took a couple years to reach alpha and to commence controlled trials in the wild with a handful of (friendly) early adopters. The feature-complete beta version was expected a year later with a planned-for public launch in 2000 or 2001. ART promised a paradigm shift in distributed computing in terms of security, scalability, language coverage, functionality and performance. A flexible and high-performance distributed computing engine; the perfect ORB to replace Orbix and overtake competition from BEA, Oracle, HP, Microsoft and others.
Engineered Stress:
It is increasingly evident that the challenge of managing the large numbers of people involved in Orbix's development and maintenance has reached a breaking point. The old strategy of hiring and throwing resources at the problem is not working so well. The company is straining under the classic problem of hierarchical organisations: the need to maintain clear communication and coordination within layers of management, large numbers of people, and offices around the globe. They also have to balance a diverse portfolio of historical and new product development projects by coordinating teams (and teams of teams) in an intricate choreography with idiosyncratic interdependencies between different versions of Orbix.
Over the last year or so Iona's C-suite (CEO, COO, CTO, CFO) have appointed a number of executives from the Telecoms, Banking, and Aerospace industries. These executives are very familiar with standard management framework approaches for technology production such as the RUP (Rational Unified Process), ITIL (Information Technology Infrastructure Library), the CMM (Capability Maturity Model), and ISO9001.
Steve Vinoski, Iona's chief architect, leads the ART team in Boston but travels to Dublin frequently. Steve, a former systems architect from HP, has long been involved in developing open computing standards. He was an early advocate for object oriented programming and design patterns and although having a big-company background is skeptical about standard management framework approaches. Steve has been spending a lot of time recently talking with Kent Beck about this new practice-based approach called Extreme Programming.
Steve has asked the dev leads and engineers to review the current situation and propose options to improve the situation. He says ``There must be a better way to organise!' Many of the engineers agree. Orbix PD and CE teams are increasingly dissatisfied.
 |
| Heavy mental "Back to our roots" (image credit: Joe McCarthy, 2000) |
The Orbix dev leads (Mary, Aileen, Tim, Jan Willem, and Charlie) call themselves the junior management team – all of the pain, none of the power. Between them are responsible for all Orbix engineering or support. In addition to maintaining all legacy products they have been asked to design forwards compatibility with ART so that customers can easily migrate their systems when ART is finally released.
Comments gathered from a recent internal survey carried out by HR give a sense of the mood.
'More inter-departmental cooperation please, people feel guilty asking questions.' [Anon]
'Get CE and Engineering teams working closer and get rid of the quick fix mentality.' [PD engineer]
'Outrageous workloads are destroying me, there must be an end in sight?!' [CE engineer]
“Product milestone dates come down from ‘on high’, the teams should estimate them, not some diktat.” [PD engineer]
'The company is a fun and challenging place to work, it’s "challenging" when we over-commit…' [CE engineer]
'We need workable processes to get us moving between teams and products.' [CE engineer]
Workload and stress is increasing. There is a lot of `needed' yet unrewarded overtime and some people seem to practically live in the office. There is talk of setting up an on-call rota to provide out-of-hours software support and a rumour that the Orbix team is going to be cut rather than boosted is doing the rounds. More demands with fewer people! They are already putting in huge hours and effort to come up with fixes, release patches, and keep customers happy. It feels like something is going to break. To make things more complicated, many feel that working on Orbix (with its old but familiar complexity) is a dead-end. They want to learn to use ART (the shiny new thing).
