Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Architect's Training Program
Transcript of Architect's Training Program
Inherent in all systems and infrastructure
Spontaneous or conciously designed Application architecture
System architecture Architectural Frameworks Zachman Framework
TOGAF: The Open Group Architecture Framework TOGAF ADM Preliminary Framework and Principles Architectural
Vision Business Architecture Information System
Architecture Technical Architecture Opportunities
and Solutions Migration Planning Implementation
Change Management TOGAF Architecture Development Method (ADM) An Architecture must be motivated by business requirements
–Why do we need i.e. a three-tier solution?
Architecture is key element for maintainability and reusability
Architecture defines non-functional requirements
–Ability to endure changes
–Reliability An Architect has to know not just the key functional requirements but also
the non-functional requirements
the key drivers for the system (i.e. cost, time-to-market, flexibility, etc.)
the constraints to architecture (i.e. technology and their limitations, legacy systems, etc.) Non-functional Requirements, Quality Attributes:
Only stakeholders know them!
QAW – Quality Attribute Workshop, scenarios
The QAW generates an informed basis for architectural decisions
Important to summit all stakeholders because of...
CYA: Documentation (in whichever form) is important for Architect's survival Examples of Quality Attributes:
Cost (also license model) and schedule
Marketability (market window)
Appropriateness for organization
Performance (response time, utilization, throughput)
Security and stability when provoked
Availability and reliability (MTBF, MTTR, etc)
Usability, learnability, efficiency, deployment
Customization Top 5 requirements on the Architect:
Focus on Quality Attributes
Enforce coding guidelines
Use architectural principals, patterns and tactics
Bear in mind infrastructure and environment, use deployment views and follow your deployment strategy
Maintain and develop and evangelize the architectural vision Volvo Cars' 10 architectural principals:
Autonomous modules and loose coupling
Performance from day 1
Maintainable How to counter NIH Syndrome:
Publish a web site with existing web services, how many systems are using it and its author.
Requires monitoring and accounting in the services (but you were going to implement that anyway, right?) SOA ≠ Web Services
Web Services ≠ SOA
All services, web services or other, must have an SLA (Bacardi)
The 4 tenets of SOA:
A Service is autonomous
A Service has explicit boundaries
A Service exposes schemas and contract (NFR), not class or type
A Service allows or denies use based on policy Purchasing (or developing) of a system must be made with an intended life length in the company, be it the economic depreciation time if no other data is known – but make it as an informed decision! Views of software architecture:
The 4+1 View by Philippe Kruchten (Rational) There are tactics for each of these attributes/properties that
helps you choose applicable patterns:
Safety and reliability
Security: specify cost for theft and loss of data
Testability: how to handle exceptions, adjustable logging, etc. Example of a package structure:
com.nissan.services.buildsandprice.dao.sqlserver.impl What is a good architecture?
Abstractions are clearly layered and the layering is visible
Higher-level abstractions build on lower-level abstractions
Reusable parts are separated from replaceable parts
The interface and implementation of each layer are separated from each other, thus making it possible to replace and reuse the implementation SEI Standard Organization of Interface Documentation:
1. Interface identity (name and version)
2. Resources provided (resource name and arguments, results and pre-requisites
3. Data types
4. Error handling
5. Variability (configuration parameters)
6. Quality Attributes characteristics (performance and reliability issues)
8. Rationale and design issues (motivation behind the design, future changes)
9. Usage guide Design by contract (Bertrand Mayer):
External view of public services
– What it does
– Return values
– Pre and post conditions Core principles of interface design:
Generalize interface with generic types and operations (but don't make them completely anonymous and meaningless)
Use transfer objects if possible instead of parameter lists
An object's responsabilities is based on
+ Doing something (either self, by delegating, or by coordinating)
+ Knowing something (own state i.e. attributes, things that can be calculated or derived, other objects) Attribute-driven design (ADD) is based on the QA and the QAW, and recursively (top-down) splits the system into architectural elements by using tactics and patterns.
Each requirement has an importance ranking (H, M, L) to stakeholder and architecure. The five with highest ranking (H,H) are the architectural drivers. How is architecture related to the Agile manifesto?
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan Developing an Architecture using Scrum:
First sprint (or call it the sprint zero) builds the architecture on which the later sprints build
Architecture and infrastructure are high priority non-functional requirements
Must be completed to prove that functional requirements can be implemented satisfactorily, that means sprint zero too has to deliver at least some business value
However, the above does not mean that all architectural components must be 100 % complete, it means that you cannot cheat and take shortcuts.
Posten AB has code structure/skeleton available as a template. Testing and monitoring: "nothing new under the sun".
Root cause analysis is important (as if we weren't aware of that) Business Process Modelling: Should be performed when building or buying a new system or application, or when integrating new functionalities into existing systems.
Causes strong and sometimes hard feelings; changes in the business process and failures to perform is often blamed on the new system (whether it's correct or not) Business Architecture is the grouping of business functions and business objects into clusters "business domains", which has meaningful accountability.
Contains the most important business activities in the core business. For us that would be purchasing and selling goods, not refilling paper in the copy machine or having the "kitchen week" :-) Business Process Management, which is the governance of the processes AND the technology involved. More TLA's:
BPMS (BPM System) = BPMN (BPM Notation) + BPEL (BP Execution Language) + Web Services (+ BizTalk!)
Pitfall: one concentrates to much on the tools that the business uses and their usage, and studies them in too much detail.
BPI = BP Improvement, will most certain generate resistance in the organization... requires *lots* of communication, a strong sponsor, and evangelists that people trust and follow Information Architecture, related to what others call Master Data.
Without IA, identical or almost identical information is entered, stored, and maintained in several places.
The IA is usually on the conceptual level without implementation details.
Also in Scrum sprint zero (or even sprint -1)...
TOGAF defines several views to IA, where Data Lifecycle View was new to me
No TOGAF IA view explicitly defines the business owner of the data, but the System Engineering View shows which system that "owns" the information (i.e. stored and maintained) Universal Data Models
Is da shit!
ISBN 0-471-38023-7 Enterprise Integration Architecture
There are many styles, techniques, and patterns to choose from...
http://www.eaipatterns.com/ Finally, we're getting to SOA... First, some fundamentals:
Services are reusable
Minimizing internal dependencies using facade pattern
Services are independent and stateless
Service omponents provide coarse-grained interfaces; however, it can be difficult finding the right level of details
Services are described in a standard way, and are catalogized and searchable (UDDI)
Possibly also published in a human-readable popular form.
Look, another cool TLA: ESB! (pt 2 page 59) SOA design starts from the need of business processes, but it's not an architecture of a single project, it's organization vision – Service Oriented Enterprise
If there's no BPM, there's no SOA. Worth thinking about! :-)
SOA Portfolio Management
SOA Production Support for Platform, Service, and Integration
SOA Program Promotion and Marketing
SOA Reporting, Analytics, Monitoring
Decommisioning Interesting discussion on versioning web services:
Initialize, Initialize2, Initialize3, ...
Version number as parameter:
XmlDocument BookTicket(version, XmlDocument)
will require anonymous type as data. Bad, bad to the bone!
Same method name, schema name has version:
Who own a service? Who makes decisions on changing the service? Who owns the data?
Who owns common services that several business processes uses throughout the organization? IT?
What if requirements or change requests conflicts?
Maintenance policies for deployed services?
How can the service be monitored? How deep must an IsFunctional() call go for a service to be considered functional, taking into fact that a database call can be costly?
SLA's? SOA Taxonomy (how a service is named and catalogized):
There are several taxonomies available
A general recommendation is to use the names from the business model
There are a few no-no's:
Just a thought-up example, we haven't done our homework yet!!! SOA is like a puppy!
SOA needs constant supervision, nurturing, clear boundaries, someone in charge... Availability percentages and what they really mean:
Unplanned unavailability – downtime outside SLA, these figures are for a 24/7 SLA:
99 % means 3.5 days / year downtime outside SLA
99.9 % means 9 hours / year downtime outside SLA
99.99 % means 50 minutes / year downtime outside SLA
99.999 % means 5 minutes / year downtime outside SLA Technology architecture
– not a list of approved software and vendors
– knowledge and training, rights management, authentication and authorization, verification of actions (incl. audit trail), segregation of critical parts, segregation of duties, intrusion detection and prevention, encryption, PCI, PUL Architecture Quality
How to analyze an architecture:
ATAM (Architecture Tradeoff Analysis Method)
CBAM (Cost-Benefit Analysis Method)
ATAM is business requirements-oriented and CBAM is extending it, but where do you get the figures from? How do you put values (not necessarily monetary values) on 2 sec response times instead of 0.5 sec? Documentation... did you really think you could get away without it? Again?
All normal rules apply: Write from the intended reader's point of view, avoid repetitions, keep it current but not too current (i.e. on a reasonable detail level), fitness of purpose, etc.
Avoid ambiguity, i.e. always write "the system" or whatever you are documenting, don't use referrals such as "it", people may interpret different
Record rationale, i.e. why did we chose a particular design, which QA made us choose MSMQ instead of files?
Keep in mind the 4+1 views!
Note to self: Managers seldom reads sentences larger than 10 words, write bullet points instead with lots of white space around...