Building IT systems: How the real world may challenge your perfect design

1. Henrik Vosegaard – IT Architect, IBM Application Innovation Services 19 November 2010 Building IT systems: How the real world may challenge your perfect design

2. Introduction • A few words about me and why I’m here • My main qualification: I’m an IT-architect from the real-world  • In this lecture, I will touch upon some of the real-world aspects that influence the software we build Standard products or custom development How is the delivery team organized? What are the business requirements? Do they remain valid? Who makes decisions? Software architecture and design Are the stakeholders committed and in agreement? The agreement (contract) with the sponsor Other systems to integrate with? Can it be administered? Maintained? Hosted? Security

3. Who makes decisions? • Often the stakeholders may have different ambitions with an IT solution • Users: Ease of use, support daily routines • IT-department: Can it be administered, hosted and maintained? Protection of earlier investments • Consultants/architects: Architecture and Design principles • Management: Measure and optimize business performance • ... • Often, all of them are allowed to put requirements forward as input to negotiations with a vendor • This is how major IT projects are born! • But some stakeholders have more influence than others • It may save your project from a lot of side-tracking if you find out who...!!

4. Exercise 1: Let’s build an electronic patient record (EPJ in Danish) Finance dept.: Billing is the most important! Clinical users: It should be easy to work with! The architects: It must fit into our enterprise architecture! Management: We have a business case... Our EPJ Clinical board: We must comply with international standards Users and IT dept: We need integration with the booking system Clinical board: We want standardize treatment plans Ministry of Health: You have to use our data/process model ... oh, by the way: we have some data privacy regulations

5. Booking The architecture for our EPJ Users and IT dept: We need integration with the booking system Clinical users: It should be easy to work with! UI ... oh, by the way: we have some data privacy regulations Client Server Clinical board: We want standardize treatment plans Business Logic Terminology & templates Clinical board: We must comply with international standards Finance dept.: Billing is the most important! Data- base SST Data model Sundhedsstyrelsen: You have to use our data/process model The architects: It must fit into our enterprise architecture!

6. OK... we try again! Portal Booking UI Patient Component UI UI Client Server Booking Business Logic Patient Component Business Logic Business Logic Terminology & templates SST Data model DB Decoupling Layer • Everything must be fitted in here • Encapsulation and data relations? E.g. • Referential integrity • Is it OK if two components update the same table? • My rows, your rows? Data- base Data- base Home-grown model Pre-definedmodel

7. Why can’t we always be agile? • A classical project life-cycle for IT delivery (”Waterfall” method) • Analyze requirements • Design the solution • Implement the solution • Start using it! • What could be the drawbacks of this approach? • Let’s think of agile as: At any given point in time, we build what generates optimal value • What could prevent agility in software development? • And maybe justify the waterfall method...?

8. Agreements • Ideally, the IT vendor and the customer develop the requirements together • But public tenders are often different • the requirements are worked out in advance • they are difficult to negotiate due to fairness-policies • they may contain minimum requirements that must be met • they must be delivered according to fixed conditions: price, time etc. • How would you approach this as an IT vendor? • How to handle requirements with a high degree of uncertainty? E.g. • Migration of existing solutions • Integration with other systems whose interfaces are not well-documented • Organizational implementation of the solution • What will happen if you make assumptions that turn out to be incorrect? • Can you be ’agile’ under such conditions?

9. The SOA promise? • Support for business processes – ideally with a high degree of automation • Replaceable service components exposing reusable services (atomic or composite)

10. What do you think of the SOA approach? • What are the benefits and drawbacks of a SOA architecture in terms of • Organizing the project? • Agility / changing requirements? • Quality of service • high availability? • high throughput? • Maintaining the solution(s)? • Is it the best approach when building everything from scratch (no legacy)? • ...

11. Suppose you accept the idea of having an architecture... • Consider the system context: Which interfaces must the system have • Define a component model: • Break down the solution into logically meaningful pieces from the requirements • Should map to functional requirements • Should be cohesive (”self-contained”) • Should have well-defined, simple interfaces • Can be functional or infrastructural • Consider implementation alternatives for each component • Buy or build? • Do you have the skills in your organization? • Note that ”buy” also will require skills and will complicate agreements • How do you meet non-functional requirements? • Define the interfaces/services exposed by your components • This may be an iterative process • What kinds of requirements do you need up front? • Interfaces may be expensive to change. Why?

12. Wrap up Thank you for your attention Please visit: ibm.com/university You are also welcome to contact me: Henrik Vosegaard IBM Application Innovation Services hkv@dk.ibm.com