Architectures:the Good, the Bad and the UglyMiha KraljSenior ArchitectMicrosoft

2

Establish Objectives,

BuildCredibility

Trust me,

I’m from Redmond and I know what

I’m doing

3

Let’s dig into some

architectures!

4

Who is Architect anyway?

Architect is what Architect does.

5

Architecting is just an advanced form of hand

waving, right?

Architecture• Structures and relationships, static and dynamic views,

assumptions and rationale• Focus: decomposition and allocation of responsibility,

interface design, assignment to processes and threads

Architecture Guidelines and Policies• Use model and guidelines; policies, mechanisms and design

patterns; frameworks, infrastructure and standards• Focus: guide engineers in creating designs that maintain the integrity of

the architecture

GuidesDevelopers

Architecture Strategy• Architectural vision, principles, styles, concepts and mechanisms• Focus: high-level decisions that will strongly influence the structure of

the system; rules certain structural choices out, and guides selection decisions and tradeoffs among others

Guides Architects

Conceptual Architecture

Logical Architecture

Physical Architecture

6

Narrowing the focus

Execution Architecture Process, Component, Deployment View

Logical Architecture Detailed Diagrams, Functional Specs

Conceptual Architecture

Abstract View, Component Break-down

Meta-Architecture Architectural vision, style and principles

Ignoring what can be safely ignored

7

Patterns(good stuff)

Anti-patterns

(bad stuff)

PatternsPredictabl

e, recurring events

8

Word of Wisdom

Always compliment

women. Nobody really cares if they are well-dressed

or not.

9

Analysis Design

Architecting

(What do we do?)

Requirements

10

Ctrl-CCtrl-VCtrl-ACtrl-C

Case study:Biztalk for

Office

Ctrl-V

Remember the preference

(aka Notepad Paste)

11

Anti-pattern:McKinsey Syndrome

Opposite Anti-pattern:

Obedient Butler

•We know it all, we don’t need to listen…•They don’t know what they really want…•Just a cookie-cutting re-delivery…

12

Anti-pattern:Napkin Doodle

Opposite Anti-pattern:Documentation

Overkill

• It was so straight-forward requirement…•We agreed on all req’s during lunch…•Light projects don’t need heavy process…

13

Case study:The wall of

painUser LAN

User LAN

Backup LAN

Backup LAN

Mgmt LAN

Mgmt LAN

iLO LAN Heartbeat LAN

Heartbeat LAN

iSCSI SAN

iSCSI SAN

User LAN

User LAN

14

Anti-pattern:Measure abuse

Opposite Anti-pattern:

Softie-softie

•Each req must have success metrics…

•If you can’t measure it, it is not there…

•We need binary criteria of achievement…

15

Design

RequirementsAnalysis

16

Case study:Me-too Flickr!

Enterprise? Cloud??? OMG…

Single user Peer net

17

Anti-pattern:Start small, grow

fast

Opposite Anti-pattern:Let’s Go Global

NOW!

•Just for couple of users first…•Prototype, patch-up, deploy…•We’ll add scalability later…

18

Anti-pattern:Best-of-breed

Opposite Anti-pattern:

Vendor Lock-in

19

Anti-pattern:YAGNI

•I’m sure nobody needs this requirement...•I bet this one is totally irelevant…•Too low on priority list…

Opposite Anti-pattern:Analysis Paralysis

20

RequirementsAnalysis Design

21

Case study:Document

Management

22

Anti-pattern:Reinventing the wheel (aka

NIH)

Opposite Anti-pattern:

Golden Hammer

•We can do it better. Much better...•It would be boring to re-use the old stuff!•I trust my code and my code only.

23

Case Study:Sell me

some stuff, baby!

24

Anti-pattern:Sales-driven

Design

Opposite Anti-pattern:

Technological Purity

•We sold it, you just implement it…•Trust me, I’m technical too…•Does it work? Shut-up then…

25

Anti-pattern:YAFL

Yet Another Fine Layer

Cream

Sponge

Custard

Berries

Sponge

Custard

Berries

Sponge

Custard

Yum!

Architecture is simplicity, not

intellectual violence.

26

SQL Server

Project Server 2003

Project Professional

2003

PdsRequest.asp

UsernamePasswordGo wild,

grab data

Case Study:The world is flat

Tier 1

Tier 2

Tier 3Tier 2!

POST http://SERVER/projectserver/logon/pdsrequest.asp

<Request> <GetInitializationData> <Release>1</Release> </GetInitializationData> </Request>

<Reply> <HRESULT>0</HRESULT> <STATUS>0</STATUS> <UserName>mihak</UserName> <GetInitializationData> <GetLoginInformation> <DBType>0</DBType> <DVR>{SQLServer}</DVR> <DB>ProjectServer</DB> <SVR>SERVER</SVR> <ResGlobalID>1</ResGlobalID> <ResGlobalName>resglobal</ResGlobalName> <UserName>MSProjectUser</UserName><Password>P@ssw0rd</Password> <UserNTAccount>SERVER\USER</UserNTAccount> </GetLoginInformation> </Reply>

27

Words of Wisdom

Man who eats many prunes gets good run for money.

28

Modularity(degrees of freedom)

Supported scenarios:

29

Open-ended systems

(specific vs. generic)

1965 2010

100%

0%

Func

tion

Assembler COBOL SQL Web

Application-Specific

General-Purpose

Application Logic

Business Process Logic

Data Logic

Data

Application-Specific: SolutionGeneral-Purpose: Infrastructure

30

Wu WeiBuild to grow

WeiBuild to

specifications

Not Make;An engine of Continuous

Transformation

Make;An engine of Immediate

Purpose

31

Identifier Format Protocol

Identifier, Format and Protocol

IP Address IP packet IP ProtocolTCP/IP

@ Address RFC 2822 SMTPE-mail

URL HTML httpWeb

URI SOAP envelope

SOAP payload

Ws-*

AddressReference

Name

DocumentMessageContainer

MethodOperation

Process

Back to the Roots

32

Middle-out

Architecture

Uncertainty

Uncertainty

SimpleInterface (IFaP)

Generic Solutions

Federated Components

Minimal Spec

Wide range of implementations

Wide range of uses

33

Poor-man Application Model

MicrosoftMicrosoft

AppM

odel

AppM

odel

AppM

odel

AppM

odel

AppM

odel

AppM

odel

Atom, RSS, HTTP

Generic AppModel

34

Web-Oriented Architecture

(Thin-waist design)

Salesforce.co

m

RESTful operations

10mio calls per day

live.com

Live API

Live-aware apps

Amazon.com

AWS

Thriving ecosystem

35

Words of Wisdom

Thin waist will make you

pretty.

36

Lines matter more than boxes

RecordsMgmt.

OrderMgmt.

Inv./Shipping

CRM

Current Model

CheckoutProtocol

InventoryProtocol

Data Retention Protocol

CRMProtocol

Future Model

Protocols are inherently stable. Applications are

not.

37

Data Code

Gen

eral

Spec

ific

Unstable Stable

InstanceData

Metadata Class

Instance

ImproperDependency

Dependency Inversion

Fold knowledge into data, so program

logic can be stupid and robust

What needs to be easy to understand

and change goes into data

What will be stable goes into code

Data should depend on code.Code should not depend on

data.

38

New-age development

"Service"

Gen

eric

Ren

derin

g

Eng

ine

Data

Gen

eric

Pro

cess

Eng

ine

Data

Gen

eric

Rul

e

Eng

ine

Data

Gen

eric

Dat

a

Eng

ine

Data

Parser

Generator

<Rules>e.g., BRML

<Processes>e.g., BPEL

<Views>e.g., XQuery

<UI>e.g., XHTML

"Service"

DataDataData Data

Parser

Generator

<Rules>

<Processes>

<Views>

<UI>

Update

Edit Response

Request

SoftwareMetadata

GenericRule

Engine

GenericProcessEngine

GenericData

Engine

GenericRendering

Engine

Model-Driven Design

39

Virtual worlds, virtual rules

Guest OS

App BApp A

Guest OS

app

Owned by Company A

Owned by Company B, executing on the host

Owned by Company C, streamed to the host

Owned by User, running in the Geoplex, streamed to the host

Shared, temporary owned for contracting purposes

40

Automation of Application Development

Programmersvs.

Machines

Reaching human limits

When process, platforms, technologies, workforce and governance are defined in advance and rarely met.

Quality

Limited by human nature — you can enter code no faster than you can type. Limited multitasking.

Speed

Cheap (offshored) AD labor is limited by socioeconomic factors.

Cost

Manual Labor

Machines' way of life — virtually unlimited

When process, platforms, technologies, workforce and governance are measured and improved in real time

Unlimited multitasking and variables handling

Machines

What could be cheaper than "software machine" with industrialized production?

41

Words of Wisdom

We always need strong hands on the

plow.

42

Your next steps

•Today•Start thinking strategically(be an Architect, not an Engineer!)

•Near future•Define principles, policies and guidelines that transcend technologies

•Longer term•Buckle-up – we ain’t see anything yet!