Chief Technology Officer
Nobody really likes non-functional aspects of IT-systems. Yet they are crucial. How to make the requirements explicit and map them to solution design, infrastructure configuration and operational monitoring and management? Agile, DevOps, Cloud, Automation have pushed the non-funky stuff to the fore. The non-functional characteristics of your IT systems can make or break them. Failing security, inability to scale, poor availability, excessive costs, dismal performance, operational mismanagement. We tend to spend too little time a little too late on non-functional aspects. Because they are not funky. Or not entirely understood by the business. Or not completely grasped by the application development team. We simply cannot afford that. In this session we will use a structured approach to identifying and recording these non-functional requirements and designing our solutions accordingly, with future change in mind. Learn how to never leave the non-funky stuff out of our collective sights. Non functionals always have been important. The elasticity of the cloud (and the associated bill), the automation of many operational processes, the required agility of applications, increasing focus on security and the expanding responsibility of development teams into DevOps are all reasons by non-functional aspects of applications are rapidly becoming more prominent. We need to find a structure way to discuss non-functional aspects – as DevOps team as well as with the product owner and business stakeholders. How to incorporate requirements into solution designs, how to test for non-functionals and monitor current state of affairs to react and predict in order to pro-act. In this session I will discuss the non-funky diagrams I have created to visualize the non-functional requirements from a business level and mapped them all the way down to infrastructure. To find bottlenecks in scale, cost, performance and availability, to identify attack surfaces, and spot decoupling opportunities. These diagrams are a useful tool to bring various types of specialists together and discuss design options and the impact of choices. Outline: the project: overran the budget by 200%, double the time and the system is still unstable and way too slow. Technology: Java on Azure – how to find the causes of brittleness? – how to find the performance bottlenecks? – how to find the availability undermining factors? Introducing a way to visualize the non functional characteristics of systems across multiple tiers (from functional end-to-end chains to bare infrastructure components) How to plot requirements? How to find the waterbed effect? How to design (meaningful) redundancy & fail over? Applying this non-funky visualization style to the doomed project – and getting a handle on it.
Software engineering is programming with the added dimension of time: programs that can evolve and scale, be maintained and be operated by multiple people over a longer period of time. What does it take to do software engineering in a professional manner – beyond mere programming? As programmers, our main goal is to make IT work. To translate functional specification into executable code. And sure, that is the least we can do. But we have more responsibility than this. We have to produce software that is robust and will reliably handle expected and unexpected cases. Software that is scalable and can handle expected and somewhat unexpected load gracefully. With minimal operating costs and in the greenest way possible. Software that is observable and manageable and that can be evolved with changing and new functional requirements and with changing technology. Software that will be legacy in the original, positive meaning of the word. That does not depend on the one big brain in our team or on the guy that has been around for three decades. Software that we know is good and can comfortably be modified in a controlled and productive way. We have to grow from excellent programmers to professional software engineers. This session talks about what it takes to create our code with honor. It discusses automation at every level in the build, rollout and monitoring of infrastructure (as code), platform and application, using CI/CD pipelines and DevOps procedures and tools. The session talks about testing – before and during development as well as after each change anywhere in the system and for both functional and non-functional aspects. Test driven development, regression testing and smoke testing are among the concepts discussed. The term ‘clean code’ refers to code that is readable, testable and maintainable. Through code analysis and peer reviews and by performing refactoring we constantly refine our software to be collectively adaptable. The session demonstrates the concepts discussed with code samples in the context of cloud native programming. As software engineers, we have an obligation to society, to our peers and to ourselves to not only write software that does the job, but to create code that is good. Ours is a great and meaningful line of work, especially if we raise our game professionally to code with honor.
The movie The Matrix made it clear: The Architect is powerful. How to be(come) and IT architect? What do you do, what do you need to know, is it fun and why? Using real world examples, core principles and useful tools, this session introduces the subtle art of designing and realizing flexible IT architectures. Taking a step back to get and create an overview, frequently asking why to get to the real intention, bringing aspects such as cost, scale, time and change and business strategy into the design and bridging the gap between business owners, process managers and technical specialists. One way to define the responsibility of an IT architect. In this session, we will discuss what is expected of the architect and what you need to do for that and what you could use to get it done. How do you get started as an architect, how to grow in that role? We discuss a number of real life architectural challenges and solution design. And discuss a number of architecture principles, patterns, and powers to apply. Never stop programming – but perhaps rise to the architecture challenge too. Notes: Many IT professionals aspire to become architects. Many architects wonder what it is they have to do. After 27 years in IT I find I have slowly and steadily moved into a role that I can probably use the label architect for, although still with some reluctance. What exactly does that mean – IT architect? While I may not have all answers and the ultimate truth and wisdom, I do have many architectural challenges to discuss and some core principles to share and a number of tips, tricks and tools to recommend that will help anyone get started or grow in a role as architect for software and IT systems. Elements that make an appearance include cloud, agile, DevOps, microservices, persistence, business, powers of persuasion, diagramming, cost, security, software engineering, data. Outline: – two real world examples (one new business initiative, one running and struggling project) and how to approach them with an architect's mind – core principles to apply , patterns to us, what to unearth (the power question of WHY) – architecture products: what do you deliver as an architect; how do you ensure agility? – how to be effective? bringing your design to life – communication with stakeholders/powers of persuasion, monitoring adherence, being pragmatic but not lose grip; – anecdotal evidence from several small and large product teams – the good and also the ugly (architectural oversights and the consequences) some specific answers to address – how much technical knowledge and programming skills does an architect require? What other knowledge is required and how to stay on top of your game? how to get going: first steps towards be(com)ing and architect?
How to take 100s of local Oracle Databases and consolidate them on the cloud into a single database, retaining only access to local data for each location (answer: VPD) and with multiple releases of applications and databases running side by side (answer: Editions). A critical platform rejuvenation. Dozens of Oracle Databases – each health center location has one on its local server with the same data model and the same set of applications. These databases have to be centralized and cloudified and also be consolidated into one or as few databases as possible. To lower costs, ease operations and enable innovation. Each location can access only its own data, applications do not have to be changed and different locations can run different versions of applications and database objects. This is the story of a critical migration. About the cloud ready analysis, the Proofs of Concept with Oracle Database features VPD and Edition Based Redefinition, the scalability investigation, the redesign of change management, rollout and operational management processes and the careful modernization of a 25 year old platform on the latest database release and a shiny new, fully automated cloud platform. This is the story of an organization that had state of the art systems in the mid-90s. And they have these same systems today – no longer state of the art. They can keep the systems alive, but barely, and at increasing cost. In the Fall of 2020, we started an investigation into the feasibility of bringing the 100s of databases from each of the locations together, in a central location, in the cloud and finally: consolidated into one or at least as few database instances as possible. Using Oracle Database Virtual Private Database and Edition Based Redefinition, a smart database connection configuration in each store and a limited reimplementation of non-cloud/non-consolidated mechanisms (interaction with local file system for example) we have designed and proven a working new design and migration approach.
The 6R model describes six ways to move systems forward. Oracle systems – database, middleware, custom applications and integrations – need special consideration and treatment when defining their roadmap. This session discusses these considerations and outlines forward strategies. Real life cases are used to illustrate the points made. The cloud is changing many things. Even the decision to not (yet) adopt cloud is one to make explicitly. Now is a time for any organization to reconsider the IT landscape. For each system we should make a conscious ruling on its roadmap. The 6R model suggests six ways to move a system forward. This session uses the 6R model and applies it specifically to Oracle technology based systems: what are the options and considerations for Oracle Database, Oracle Fusion Middleware, custom applications and other red components. What future should we consider and how do we choose? The paths chosen by several Oracle-heavy users is presented to illustrate these options and the decision making process. Oracle Cloud Infrastructure and Autonomous Database play a role, as do Azure IaaS and Azure Managed Database as well as on premises systems. Latency, recovery, scalability, licenses, automation, lock-in, skills and resources all make their appearance.