Architecture Matters

Erik Wilde, School of Information, UC Berkeley
March 7, 2011
`http://dret.net/netdret/publications#integrative-spring11` [http://dret.net/netdret/publications#integrative-spring11]

[http://creativecommons.org/licenses/by/3.0/]

This work is licensed under a CC
Attribution 3.0 Unported License [http://creativecommons.org/licenses/by/3.0/]

<a class="extra " href="http://blogs.ischool.berkeley.edu/i290-iw/" title="http://blogs.ischool.berkeley.edu/i290-iw/">Integrative Workshop</a><span class="print-href"> [http://blogs.ischool.berkeley.edu/i290-iw/]</span>, Spring 2011

Erik Wilde: Architecture Matters

(2) Abstract

A good business model and good service design are necessary requirements to implement a successful information-oriented project or business, but implementation issues still can have a great impact on the chances of success. Technical design and implementation are not a mechanical process of defining an abstract model, and then pressing the generate system code button. Important architectural issues cover questions of data model design and implementation (which metamodel is used, what are the planned extensibility and openness points, how well is extensibility and openness planned and supported in both the data model and the code base), service design and implementation (what is the service implementation technology, what are the implicit assumptions about technologies that have to be supported by any user of the service), and platform strategy (what is the server-side platform, what is the client-side platform, what are the exit strategies for those platforms).

Erik Wilde: Architecture Matters

(3) Precious Snowflakes

Many applications are not as unique as you might think
- reusing design patterns and technologies is a good idea
- avoiding reuse should be justified by good reasons
Take the Web's HTML as an inspiring example
- HTML is not all that great as a document format
- it was good enough as a container for a lot of useful content
- the network effect far outweighs its functional shortcomings
Simplicity and easy applicability are valuable
- simplicity means a lower barrier to entry
- easy applicability means higher chances to create network effects

Erik Wilde: Architecture Matters

(4) Architectural Challenges

Effectiveness over Efficiency
- design should result in effective implementations
- efficiency depends on design (and thus is one important constraint)
- flexibility and openness may be at least as important
Refactoring services and data models is hard
- hitting the sweet spot between overspecialization and overgeneralization is hard
Design has become much harder than it used to be
- the platform landscape is changing rapidly
- the competition landscape is changing rapidly
- it is very likely that interoperability will become important

Examples

Outline (Examples)

Examples [2]
SOA Metamodels [9]
Data Metamodels [2]

Examples Erik Wilde: Architecture Matters

(6) Synchronization

Offline-capabilities can be essential for applications
Many (even mobile) applications have terrible offline support
- not easy to do well but easy to get wrong
Synchronization is very tightly coupled with the data model
- things must have a global and stable identity
- things must have ways how to get created/updated/deleted
- there must be some way for clients to query the update stream
What are the characteristics of synchronization?
- few updates (manual reports) or many updates (sensor readings)?
- complete synchronization or only with a limited horizon?
- are overwrites possible and can they be concurrent?
- how critical is it to prevent outdated views?

Examples Erik Wilde: Architecture Matters

(7) So you want to be a Platform?

Have at least a few possible platform users
- what are the constants, what are the variable parts?
- will applications need freedom in adding structured data?
- if applications can add structured data, can they query it?
Consider all possible target users of your platform
- what are the technological requirements to become a client?
- what is the knowledge required to become a client?
- do you expect few users or do you expect many users?
Eat your own dog food
- build your own application/interface using your own API

SOA Metamodels

Outline (SOA Metamodels)

Examples [2]
SOA Metamodels [9]
Data Metamodels [2]