Presentation: "Big Ball of Mud: Is This the Best that Agile can Do?"
Time:
Wednesday 12:05 - 13:05
Location:
Stanford Room
Abstract: It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?
Presentation: "When should you consider meta-architectures?"
Time:
Friday 14:05 - 15:05
Location:
City Room
Abstract:
There are times when a system must adapt to new requirements within months or weeks rather than years. These new requirements can include complicated rules and new products or services the organization needs to scale to suport. As the system scales up and becomes more complicated it can become very hard to adapt quickly to these changing requirements. In fact, the system can even become harder to change and slower to accept new requirements. This can lead to a desired architecture that is designed to scale allowing the system to more easily adapt to changing requirements.
Do you have the goal of building a system that can be extended and adapted without programmer intervention? Do you have the itch to explore meta-programming, not just because it is cool or complicated, but because you want your system's behavior or domain representations to scale? If so, consider learning about the design of systems that represent user-defined behavior specifications as metadata.
Architects create Adaptive Object-Model systems when they want to enable end-user programmers to adapt their system's behavior and they don't want developers to become the bottleneck. But what does it take to build a system that can be changed and adapted without programming? How do Adaptive Object-Models differ from little languages or DSLs and when is it appropriate to consider stepping into the meta world to build such an extensible system? This talk presents the basic ideas about meta-architecture such as an Adaptive Object-Model architecture and shares experiences that the presenters have had building and tuning various production meta-architecture systems that have enabled organizations to scale them more easily and without programming wizardry.
Training: "Rulemakers and Toolmakers: Adaptive Object Models as Agile Division of Labor"
Time:
Monday 09:00 - 16:00
Location:
Commonwealth Room
Abstract: Ultimate Agility: Let your Users Do Your Work!
Agile practices liberate us from the straightjackets of top-down design. But, the ease with which requirements can change encourage users to overwhelm us with requests for features. The result: Featuritis. Adaptive Object-Models support changeable domain modules by casting business rules as interpreted data and representing objects, properties and relationships in external declarations. Now users can change the system themselves as their business dictates without having to deal with programmers at all. It's the ultimate in agility!
Agile practitioners value incremental delivery of working software. This typically means that there is not a long, involved design phase that precedes implementation. Design simplicity is also important. At first glance, Adaptive Object-Model based systems seem to fly in the face of these values. Yet we have found that under the right conditions, choosing to implement an Adaptive Object-Model architecture has made our users happier and have given them back the control they need to confidently revise, extend and grow their software on their own.
The centerpiece of this tutorial will be a presentation of the highlights of several real-world systems the authors have worked on. Our examination of each will showcase ways in which the incorporation of an Adaptive Object-Model Architecture made the systems more adaptable and our users more agile, thereby justifying the additional effort and complexity of this approach. The Adaptive Object-Model Architecture will be presented as a system that represents classes, attributes, relationships, and behavior as metadata. Additionally, a review of a process for developing AOMs will be examined.
Learning outcomes:
* See how to let users build and modify complex structures like business rules themselves, so that you, the programmer don't have to anymore.
* Learn when and when not to use this architecture.
* See how to make new types of objects with attributes, relationships, and behavior through using the TypeObject, Properties, EntitiyRelationship, and RuleObject patterns.
* Learn about the other machinery, mechanisms, end-user tools, and design patterns commonly used to implement AOM systems
* Understand when to consider AOM architectures for building end-user adaptable software.
* Understand the basics of using metadata to represent objects, properties and relationships.
* Be able to identify the risks of exposing programming and model extension facilities to users, and how to mitigate these risks.
* Learn how a system that is a model based on instances rather than classes allows users to more quickly change the system by simply changing the metadata (object model) to reflect changes in the domain.
* Understand an incremental process for developing highly adaptive systems and how important an agile process is for evolving and growing these architectures.
Attendee Background:
Attendees should have a good understanding of Object Principles. Pattern experience is helpful. Understanding agile software development is a plus along with an awareness of the basic concepts of Doman Specific Languages (DSLs).
