Talks #61 - Bogdan Bocse - What is Solution Architecture and Why You Need It?

An introduction into how solution architecture is a discipline that helps teams and organization understand technology challenges and problems before they happen. Understand why apparently free solutions may often become the most expensive. Learn to expect that having too much choice (and freedom) isn't always a good thing when building state of the art systems in the real world. Find out why integrating systems is a necessary evil that must be tamed, not avoided. And be prepared to ask questions - because defining the problem is often a lot harder than finding a solution.

Transcript

1. Bogdan BOCȘE Softbinator, February 2015
2.  Definition  Concerns  Processes  Infrastructure  Integration  Performance/Scalability  Cost  Case study: Choosing a (Big)Data Store  Things to Consider  Shopping List
3. “Information technology architecture is the process of development of methodical information technology specifications, models and guidelines, using a variety of Information Technology notations, for example UML (…)“
4. What is actually required? What are the silent requirements (expectations)? What do we have to develop? What can we reuse? Aren’t we reinventing the wheel? Do we have to integrate something? How? How much effort does it take? How much does it cost (to buy and to operate)?
5. Finding solutions to problems (performance, scalability, development, cost) before they become problems.
8. Components:  Actors/Systems/Swim lanes  Actions  Messages Helps with:  Separation of concerns  Structuring possible scenarios  Identifying untreated cases and exceptions
10.  Type  On-premise  Hosted  Cloud  Capacity Planning  Monitoring and Alerting  Redundancy/Resilience/Fault-tolerance  Disaster Recovery
12. Patterns:  Service Oriented Architecture  SOAP, REST  Publish/Subscribe  Request/Reply  Callback • Messages Queues / Enterprise Service Bus  Data Replication  Extraction-Transformation-Loading (Batch Processing) Anti-patterns:  File transfer  Shared database
13.  Performance  Non-functional requirements  Volume  Response Time  Scalability  Vertical – scale up – more powerful machines  Horizontal – scale out – more identical machines
17.  Types of Cost  Capital – how much it costs to build?  Operational – how much it costs to operate?  What you care about is …  Total Cost of Ownership (TCO)  Operational costs include  Maintenance (including staff)  Support (including staff)  Rent  Power & cooling  Backup and backup management  Spare parts
18. How to Choose a (Big)Data Store?
21. What’s it called? What does it mean? Volumetry If it’s less than 100GB, don’t bother calling it BigData Atomic Query Size Are you reading 10 or 10 million records per transaction? Load Do you expect 5 or 5000 queries per second? ResponseTime Do you expect your data store to answer in 1ms, 10ms or 10s? Immutability Once your data is written, does it stay written? Strict Consistency Do you need changes to be instantly visible to all readers? Data Freshness Do you need the absolute latest data, to the millisecond? ACID Compliance If you work with ordering or payments, you want transactions. Query Accuracy Is there room for error for the results to your queries? Persistence/Durability Should data be stored on a permanent medium (HDD, SSD)? High Availability Is it required that the data stores stays available throughout hardware and network failures?
23.  Enterprise Integration Patterns  Cloud Design Pattern and Reference Architectures  Amazon Web Service Reference Architectures  Microsoft Azure Design Patterns
24.  bogdan@bocse.ro  bocse.ro  www.linkedin.com/in/bogdanbocse  www.facebook.com/SolutionsArchitectures
25.  http://en.wikipedia.org/wiki/Scalability  http://en.wikipedia.org/wiki/Consistency_model  http://en.wikipedia.org/wiki/Fallacies_of_distrib uted_computing  http://en.wikipedia.org/wiki/Enterprise_architect ure_framework  http://en.wikipedia.org/wiki/Zachman_Framewo rk  http://en.wikipedia.org/wiki/List_of_system_qua lity_attributes  http://en.wikipedia.org/wiki/Shared_nothing_ar chitecture