Architectures Usability

1
Architectures Usability

• Memi Lavi
• Application Delivery CTO
• EDS Israel
• Memi.lavi_at_eds.com

2
Usability Defined

• usable also useable  adj.
• ltprogramminggt The effectiveness, efficiency, and
  satisfactionwith which users can achieve tasks
  in a particular environmentof a product. High
  usability means a system is easy to learnand
  remember efficient, visually pleasing and fun to
  use andquick to recover from errors.

3
Usability - Bad 1
4
Usability - Good 1
5
Usability - Bad 2
6
Usability - Bad 3
7
Usability - Good 2
8
Architecture The End User

• We develop software for end users
• We also design and develop software architecture
  for end users
• The end user of the software is the
• User
• The end user of the architecture is the
• Developer

9
Architecture The End User

• The developer must be able to use our
  architecture easily
• Or else
• The Developer is the Customer!

10
Architectures Usability - Definition

• High Usable Architecture is an architecture that
  is
• Easy to learn
• Easy to implement
• Easy to modify
• Easy to maintain

11
Architectures Usability

• Has NOTHING to do with the development platform
  chosen (.NET, Java, etc.)
• Has NOTHING to do with architectural details!
• No SOA, MVC, GoF, Design Patterns, Singleton,
  DAL, ORM, Entity Objects etc.

12
Architectures Usability Rules

• Right Architecture for the right task
• Measures
• Flexibility
• Exceptions
• Configuration
• NIH
• IDE Customization

13

• Largest Earthmover on Earth (by Krupp, Germany)
• 95 m. height, 215 m. length
• Weights over 45,500 tons
• Costs more than 100 millions
• Can remove over 76,455 cubic meters each day

14
Right Architecture for the right task

• Will we use it for this?

15
Right Architecture for the right task
1999

• - Customer wanted this

First Name
Last Name
Birth Date
Save
Close
16
Right Architecture for the right task
1999

• - Developer did this

• Open VB6
• Drag Drop controls
• Add ADO component
• Code logic in controls events
• Task DONE!

First Name
Last Name
Birth Date
Save
Close
Architecture - 0
Productivity - 100
17
Right Architecture for the right task
2006

• - Customer wanted this

First Name
Last Name
Birth Date
Save
Close
18
Right Architecture for the right task
2006

• - Developer doing this

• Open VS 2005
• Start implementing

First Name
Last Name
Birth Date
SOA
MVC
Developer DONE!
XML
Save
Close
ORM
N-Tiers
19
Right Architecture for the right task

• Remember the 80/20 rule of the programmers
• Architecture is NOT a Wish List
• Adjust the architecture to the actual
  requirements
• Small data entry applications DO NOT need to
  implement SOA
• If the application will be installed on a single
  server, dont use web services as the layers
  connectors
• Singleton wont solve all the world problems
• And so is XML

20
Architectures Usability Rules

• Right Architecture for the right task
• Measures
• Flexibility
• Exceptions
• Configuration
• NIH
• IDE Customization

21
Measures

• Some questions to ask before development of new
  architecture
• How long will it take to train an experienced
  developer?
• How long will it take to train a beginner?
• How long will it take to develop a simple page?
• How long will it take to develop a medium page?
• How long will it take to develop a complex page?

22
Measures

• Actions to perform after the development
• Thorough debug (trivial)
• Training preparation
• Training Pilot
• Development Pilot

23
Measures
Determine Architectures Objectives

• New
• Architecture
• Development
• Flow

Productivity Decisions
Architectural Decisions
Develop Architecture
Test Architecture
Improve Architectures Usability
Develop Training
Perform Pilot Training
Develop Pilot Project
Yes
No
Analyze Productivity Difficulties
Did the pilot complied with the productivity
objectives?
End
24
Measures

• NEVER start a project with a new, untested,
  unmeasured architecture.
• Or

25
(No Transcript)
26
(No Transcript)
27
Architectures Usability Rules

• Right Architecture for the right task
• Measures
• Flexibility
• Exceptions
• Configuration
• NIH
• IDE Customization

28
Flexibility

• The architecture should support 80 of app
  functionality OOTB.
• The architecture should not interrupt
  implementing the other 20.
• The architecture should supply enough Hooks to
  enable the developer to override the default
  behavior
• Under no circumstances should the developer
  bypass the architecture

29
Flexibility

• Actual Sample (From EDS)
• The architecture supports generic search page
• The architecture uses the DAL component to access
  the database
• In one page, the data should be retrieved from an
  external database
• Alternative 1 Write the whole logic for the data
  retrieval, without using the architectures
  components
• Alternative 2 Improve the architecture to
  support customization of the DAL before the
  retrieval

30
Flexibility

• God is in the fine details
• We tend to design the architecture by viewing
  The Big Picture
• but the big picture may have some scratches,
  which we should know how to handle
• Systems can become total failure because they
  cannot handle those details

31
Flexibility

• Practical tests for flexible architecture (UI,
  BL, DAL)
• Multiple databases
• Two (or more) synchronized drop downs
• Full transaction control
• Saving two tables in the same transaction
• Change drop down datasource in run time

32
Architectures Usability Rules

• Right Architecture for the right task
• Measures
• Flexibility
• Exceptions
• Configuration
• NIH
• IDE Customization

33
Exceptions

• Exceptions do happen
• The architecture should be smart enough to handle
  them appropriately
• The Developer Down Time should be minimal when
  an exception occurs
• The architecture should help as much as possible
  resolving the problem

34
Exceptions
Dont Display Generic Error Message

• NEVER assume anything
• Dont assume a certain configuration file exists
• Dont assume the configuration file is valid
• Dont assume a specific data exists in the
  database
• Dont assume the developer overrode some methods
• The only assumption is
• The developer is not you. You know the
  architecture the best, he just begins to learn
  it.
• Be prepared to handle the most extreme situations

35
The most dreaded error message
36
Exceptions
Dont Display Cryptic Error Message

• When an exception should be thrown, make sure to
  throw the most accurate one
• Create custom exceptions as many as needed
• Make sure your custom exception and message are
  specific and informative

37
An extremely helpful message
38
A real error message caught in one of our log
files
39
A quite common view in eclipse
40
Exceptions
Dont Hide Exception Information

• Throw the full information about the exception,
  when needed
• NEVER leave the catch clause empty
• If you throw a new exception, make sure to
  include all the associated information
• Use Exception Handling only when relevant

41
Why? What can I do about this?
42
Exceptions
Do Central Exception Logging

• All the exceptions should be written down to a
  log file
• The log file should give the developer the full
  understanding of what happened
• The log file is extremely useful in production
  environments
• Refer the user to the log file, and display him a
  friendly error message

43
Not too friendly, though
44
Architectures Usability Rules

• Right Architecture for the right task
• Measures
• Flexibility
• Exceptions
• Configuration
• NIH
• IDE Customization

45
Configuration

• Configuration files became extremely common
• Typical application has many XML files scattered
  everywhere
• Applications became very dynamic as a result
• Which is good.
• But

46
Configuration

• Problem 1 Applications suffer from
  Over-Configuration
• Problem 2 Configuration Scope is too narrow

47
Configuration
Over Configuration

• Definition
• When the developer spends most of his time
  messing with configuration files
• Quite common in the Enterprise applications
  field
• Often leads to the reinvention of
• Programming Language
• Compiler / Interpreter
• IDE
• Another symptom
• VERY unsatisfied developers

48
Configuration
Over Configuration

• Why do we use external configuration file?
• To allow system administrator to modify
  system-wide properties without compiling the
  application (e.g. Connection string, log
  configuration)
• To supply central location for definition of
  various system parameters (e.g. Cached data)
• Configuration files will always deal with the
  applications meta data..
• because their modification wont require
  compilation and testing.

49
Configuration
Over Configuration

• There is no point storing the core application
  business logic in an external file, because
• Every change in the file will require rigorous
  testing, and so
• The whole idea of non-compilation will be lost in
  months of testing.
• Always remember XML cannot be debugged.
• If there is an error with the XML file, this will
  just frustrate the developer.

50
Configuration
Over Configuration

• There are two ways to solve this problem
• Create a configuration IDE, which will have to
• Design the XML visually
• Validate the resulting XML
• Read existing XML files
• Be familiar with all the dialects used by your
  XML

51
Here it is
52
Configuration
Over Configuration

• Another possible solution
• Use configuration file only when needed.
• When talking about configuration, talk only about
  configuration
• No business logic definition
• No validation
• No screen structure

53
Configuration
Over Configuration

• What happens when we do need dynamic behavior?
• Use 3rd party tools. Dont reinvent the wheel.

54
Configuration
Configuration Scope

• Configuration data is usually read from an
  external configuration file, and is system wide
• What happens when there is no configuration file?
• What happens when the configuration must be
  overriden in a specific scenario?

55
Configuration
Configuration Scope

• Actual Sample (From EDS)
• External parameter defines how many records to
  display in a grid
• In a specific page, this number should be
  different
• Alternative 1 Rewrite the whole data retrieval
  logic
• Alternative 2 Override the parameter only in
  this page

56
Configuration
Configuration Scope

• Configuration should be defined in 3 levels
• Default (hard coded) not always possible (e.g.
  Connection string)
• External, system wide e.g. Web.config
• Instance usually by overriding a method
• All the configuration properties should be
  exposed as part of the architectures API

57
Architectures Usability Rules

• Right Architecture for the right task
• Measures
• Flexibility
• Exceptions
• Configuration
• NIH
• IDE Customization

58
NIH

• Not Invented Here
• From Wikipedia
• Not Invented Here (NIH) is a pejorative term used
  to describe a persistent corporate or
  institutional culture that either intentionally
  or unintentionally avoids using previously
  performed research or knowledge because the
  research and developed knowledge was not
  originally executed in-house

59
NIH

• Whose desktop is it?

60
NIH

• Apple Lisa

Introduced 1983 CPU Motorola 68000 _at_ 5
MHz Memory 1MB RAM HD 10 MB, Optional Price
9,995 Lisa is Steve Jobs Daughter Local
Integrated Software Architecture Lets Invent
Some Acronym
Lisas Mouse
61
NIH

• Apple iMac G5

Introduced 2004 CPU PowerPC G5 _at_ Up to
2.7GHz Memory Up to 8GB RAM HD Up to
250GB Price 1300
iMacs Mouse
62
NIH

• Apple Mighty Mouse

Introduced 2005 22 years of NIH syndrome!
63
NIH

• Before you start developing look around
• 3rd party products might cost money, but might as
  well save much more
• And some of them might even be free!
• With 3rd party product you get
• Debugged and tested software
• Support
• Upgrades
• Google-Friendliness

64
NIH

• Remember what you should develop.
• If the customer asked for B2B application, dont
  develop
• Workflow Engine
• Logging Mechanism
• EAI Application
• Application Server
• Database

65
NIH

• Every additional tool that will be developed by
  you, will have to be
• Debugged
• Tested
• Maintained
• Modified according to needs
• Debugged
• Tested

66
NIH

• Sample list of useful components and tools
• Log4Net
• Windows WF
• BizTalk
• NHibernate

67
Architectures Usability Rules

• Right Architecture for the right task
• Measures
• Flexibility
• Exceptions
• Configuration
• NIH
• IDE Customization

68
IDE Customization
The guys who brought us VB1 For Windows,
introduced on 20.3.1991 Since then, we can use
Add Ins in our Microsoft IDE.
69
IDE Customization

• Why do we need to customize the IDE?
• Enforce Standards
• Eliminate Errors
• Shorten Development Time
• Satisfy Developer

70
IDE Customization

• Demo
• (First and Last)

71
IDE Customization

• The DIY test
• Try to create a new page / screen in the
  application, from scratch.
• If youve got confused, youd better customize
  the IDE
• Not so easy in VS 2002/2003
• You can use Merlin
• Much Easier in VS 2005

72
Architectures Usability - Summary

• High Usable Architecture will help developers
• Learn the architecture
• Implement the architecture
• Modify the architecture
• Maintain the architecture

73
Architectures Usability - Resources

• The one and only
• www.thedailywtf.com

74
Questions?
75
Thanks!