Architecture | Methodology | Tools Why is this on the IST-DS Architecture & Design group’s agenda? 31 Aug 2010 Steve Masover & Richard Millet I’m going to set some context for this general set of discussions that we’re going to have going forward Richard will lead some, and I’ll lead some Today, Richard will talk about Dev Infrastructure, Environment and Standards; then I’ll talk about stages of realizing services

Architecture | Methodology | Tools Why talk about this? So, what’s the value of having these kinds of discussion? I’m going to chatter a bit, and while I talk you’re welcome to browse nuggets of wisdom extracted from the introductory materials of Christopher Alexander’s _A Pattern Language_. I won’t read the quotes. Are we all on that page, understanding who CA is, and how his ideas have informed software engineering?

Common Language “[...] towns and buildings will not be able to become alive, unless they are made by all the people in society, and unless these people share a common pattern language, within which to make these buildings, and unless this common pattern language is alive itself.” - Christopher Alexander, A Pattern Language, x How we do our work as software designers and developers: speaking the same language lower communication-impedance easier transitions between projects

Design pattern concept “In short, no pattern is an isolated entity. Each pattern can exist in the world, only to the extent that is supported by other patterns: the larger patterns in which it is embedded, the patterns of the same size that surround it, and the smaller patterns which are embedded in it. This is a fundamental view of the world. It says that when you build a thing you cannot merely build that thing in isolation, but must also repair the world around it, and within it, so that the larger world at that one place becomes more coherent, and more whole; and the thing which you make takes its place in the web of nature, as you make it.” - Christopher Alexander, A Pattern Language, xiii Software engineers have recognized for a while that common problems have solid solutions. Best to leverage these. applies at architectural and methodological levels as it does to OO solution design getting the details right and the big picture wrong is ... sub-optimal

Application of lessons learned “Each solution is stated in such a way that it gives the essential field of relationships needed to solve the problem, but in a very general and abstract way -- so that you can solve the problem for yourself, in your own way, by adapting it to your preferences, and the local conditions at the place where you are making it.” Christopher Alexander, A Pattern Language, xiii “We hope, of course, that many of the people who read, and use this language, will try to improve these patterns – will put their energy to work, in this task of finding more true, more profound invariants – and we hope that gradually these more true patterns, which are slowly discovered, as time goes on, will enter a common language, which all of us can share. You see then that the patterns are very much alive and evolving.” Christopher Alexander, A Pattern Language, xv SOA Kool-Aid -- canonical texts (e.g., Thomas Erl, IBM's SOAM) In KSS, CSpace, and other consortial "SOA projects," review led to assessment: what works for hierarchically governed corporate organizations doesn't map well to single universities, let alone higher ed consortia. Projects that have gone before start out down a "best guess" path, and learn what works and what doesn't Continuing and future projects that learn from past experience are better equipped to work more effectively going forward. This is the ground from which the referred wiki pages grew

Bang for buck “We begin with that part of the language which defines a town or community. These patterns can never be 'designed' or 'built' in one fell swoop – but patient piece-meal growth, designed in such a way that every individual act is always helping to create or generate these larger global patterns, will, slowly and surely, over the years, make a community that has these global patterns in it.” - Christopher Alexander, A Pattern Language, xix ROI: UCB – & other universities, museums, and Mellon – making heavy investments in service oriented projects, and needs to see return Reuse of something: Common among (consortial) projects: the promise that something (code, service contracts, skills, deployment infrastructures) is going to be shared rather than invented/assembled in specialized ways for each set of needs Code sharing is the big ROI that never seems to materialize Achievable ROI: Incumbent on us to find achievable ways to realize a return on investments for which we are responsible And that’s the point: service development principles for architecture and method are an attempt to lay out a path in this direction.

Fini Again: Today, Richard will talk about Dev Infrastructure, Environment and Standards; then I’ll talk about stages of realizing services