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.
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
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?
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
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
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
This session will provide background and guidance on how I have architected software solutions for the past 20 years. This will cover a range of mostly technical topics, including infrastructure planning, performance and scalability, separation of tiers, and software development lifecycles.