This session will provide background and guidance on how Randy has architected software solutions for the past 20+ years. This will cover a range of mostly technical topics, including infrastructure planning, trade-off considerations, performance and scalability, and separation of tiers. Expect to hear plenty of stories from real projects over his career, along with numerous tips on his secrets to success.

2. Architecting Solutions and
Systems – Secrets to
Success
Randy Williams
VP, AvePoint Client Services
randy.williams@avepoint.com

3. Randy Williams
VP, ACSAuthor

4. © AvePoint 2013
Base Principles

5. Know your requirements
 You cannot properly design without knowing what the customers’ or
market needs are
 Not all requirements will come from the outside
 As an architect, make sure you get this input. If there are missing
details, then you need to define these as assumptions.
 Bottom line is that the success of the design is whether it meets these
requirements

6. Getting good requirements isn’t easy

7. Trade off Considerations
 All design elements will consist of these
 These are the pros/cons, advantages/disadvantages, etc.
 An architect is like a judge. One who considers all the evidence and
makes a fair and balanced decision.

8. Return on Investment
 Perhaps the most important trade-off considerations, but often
overlooked
 ROI = value – cost.
 Bottom line: You want to make sure value > cost for the system’s life
 Will the choices you make pay off?

9. © AvePoint 2013
Infrastructure Architecture

10. Servers
 How many servers will you need?
 Should you scale up or scale out?
 Do you need to scale on demand?
 What about fault tolerance?
 In general, will the system be CPU
or RAM bound?
 For SharePoint farms, consider what
your roles are

11. Storage
 So many choices. DAS,
SAN, NAS, near line, HBA types,
SSD, WORM, cloud, on-prem, …
 Striping (RAID levels) is still
used to increase space and
speed, but this is much easier
with NAS and SAN devices
 Basic measure of performance is
IOPS (Input Ops per Second)
 For SharePoint db storage, target
1.0 IOPS/GB

12. Databases
 What database technology do you need?
 Do you need transactional support?
 What recovery needs do you have?
 Do you need to maintain relational integrity?
 How can you protect the database?
 What performance needs do you have?

13. Network
 Server to server, client to server
 Create VLANs, dedicated network segments
 There are lots of choices covering almost each
layer of the OSI model from application to physical
 Use caching techniques where needed
 Batch calls to reduce round trips where possible
 Leverage the power of your smart client

14. © AvePoint 2013
Cloud Considerations

15. The cloud changes most of the rules
 IaaS – we don’t think about infrastructure (hardware)
 PaaS – we don’t think about the OS
 SaaS – we don’t think about the platform (.NET, Java, etc.)
 Elasticity and Scalability gives us great flexibility
 Pay for what you use model allows us to save $$$
 Bridging on-prem and the cloud is where
things get complex

16. © AvePoint 2013
Randy’s Tips for Success

17. Tips from Randy
 Make sure you know the platform. Do your homework.
 Research other patterns and practices. It's very likely others have
designed something similar.
 Be careful if you take short cuts. Experts can get often away with this,
but I don't recommend it for others.
 Can you explain your design to your peers or properly document it? If
not, you probably don't know it well enough. Keep reviewing and
refining it.
 Architecting is often done in layers. Examples include n-tier solutions.
But also from high level to lower levels.

18. Tips from Randy
 What is the right level of detail for your design? This is hard to answer
as it depends on many factors. The short answer is when a team
understands the design and can jump right into implementation
 Consult others on your design. Don’t be afraid to let others look at it.
Be prepared to defend your choices, but be flexible and take their
input like a professional. If you need to redesign, see this as an
opportunity to improve and learn something new
 There are no perfect designs so don’t make this your goal. Your
design needs to be good enough to meet the requirements

19. Tips from Randy
 Designs are not really right or wrong. Few things in this world are
black and white like this.
 Consider the adage, "A good plan today is better than a great plan
tomorrow." - Do you think this applies to architecting solutions?
 Do not drag out the architecture for ever trying to consider every
possible angle. There are always schedule pressures whether this
comes from a customer, the market or your boss/project manager.
This will lead to paralysis.
 That said, don't rush too fast. Give it proper time. Making bad design
choices can result in weeks or months of rework. With experience,
you'll often know when it's good enough. If you don't, consult others
for their opinion.

20. Tips from Randy
 Make sure you have the architecture ready before you start formal
development. I can't emphasize how important this is and how often
it is overlooked. Doing prototype development to validate your
choices is fine, but consider it throw-away code.
 Simple designs are almost always better than complex designs.
 Make sure you think about how can you prove that your design is the
best choice. Consider how can it be tested. This happens as you
design and all the way thru development.
 Keep your code units modular as much as possible. Think about re-
use either in this solution or other ones. Think about having a library
of reusable modules. We need to continually grow this out.

21. Tips from Randy
 No one knows everything so don’t try to be an expert across all areas
 Have a good generalist knowledge about how things work and fit
together
 Then, find those specific areas where you want to specialize and
become an expert. These areas should align with your passion.
 Do what you love to make your heart sing

22. Thank you

23. Thank you
Collaboration with Confidence: Let take you there.