The Details: How Do You Develop Such a System?

My initial brief with TIBCO’s Director of Engineering was to outline the project plan as it existed at that point. What I’d expected was a
discussion of a business rationale for the product, product requirements and development roadmap. What I did not was the massive stack of paper he handed me —a spreadsheet listing thousands of services along with corresponding metrics with which to monitor them. My task: convert the speadsheet into a product.  Translation: I’d have a much greater responsibility that I’d expected. 

The lack of processes, structure and staff left me essentially on my own to figure out how to design a product within an unfamiliar, highly
technical domain whose users I knew nothing about.  The spreadsheet
was almost entirely meaningless at that point. My goal would be to
not only design the product, but define it and get it built. The
challenge to stretch beyond a strict design role: this was it. 

First Steps

As always, the first step is getting to know use cases and target users. Commandeering a conference room, I began a process of interviewing colleagues, domain experts, and customers with the goal of defining the user landscape and a starting point to uncovering what these users wanted to achieve. Bit by bit, the use cases revealed themselves, and from use cases the functional design.

The other step, in parallel, was learning about system architecture (service assemblies, nodes, containers, EMS and UDDI Servers), who created them, what problems they solved, who was affected by them. To know the user roles and goals, I’d have to understand the day-to-day work the people in these role performed.

Next Steps: Rule Builder

If there was anything obvious about the stack of spreadsheets, it was needing a tool to tie together web services and their metrics. Combined with what I’d been learning about SLAs, Business Rules and Policies it was becoming clearer that, at the very least, there’d have to be a way to assess the health of a system and limit the damage if something ever went wrong. 

How it Works

A software system —or, Service Oriented Architecture SOA— is composed of chunks of interconnected code that send and receive data. A bank customer using their iPhone to check interest rates on 30-year loans specific to her personal finance picture.

Crunching these numbers necessitates disparate systems across orgs to transact million of information bits —the federal prime rate, financial holdings, credit score, actuarial tables, property address and crime rate, natural disaster risk— and draw precise conclusions.