Developers buy into a familiar lie: “We can clean it up later; we just have to get to market first!” Ofcourse, things never do get cleaned up later, because market pressures never abate.
Software was invented to be “soft“. It was intended to be a way to easily change there behaviour of machines.
If you ask the bussiness managers if they want to be able to make changes, they’ll say that of course they do, but may then quailfy their answer by noting that the current functionality is more important than any later flexibility.
Remember, as a software developer you are a stakeholder. you have a stake in software that you need to safeguard. Thats part of your role and part of your duty. And it’s a big part of why you were hired.
The goal of the principles is the creation of mid level software structures that:
Tolerate change
Are easy to understand
Are the basis of components that can be used in many software systems
A software architect is a programmer and continues to be a programmer.
The architecture of a system should make that system easy to develop for teams.
A succesful solution requires you to understand the problem and create a vision that can be communicated to everybody incolved with the construction of the end-product. Architecture is about structure and vision.
Its anything and everthing related to significant elements of a software system; from the structure and foundations of the code through to successful deployment into a live environment.
Architecture represents significant design decisions that shape a system, where significance is measured by cost of change.
What is important, what do we as technical leadership of the project consider to be most important things?
Significant decisions are architecture and that everthing else is design.
All architecture is design but not all design is architecture.
Architecure is shared understanding between the people who are leading the project.
We need to put less effor on quality so we can build more features for our next release.
Sofrware architecture is important for moral reasons, we need to do a good job, we need to be craftsman. Unfortunately if you take that line, you have lost. Because you are making a batte between craftsmanship and economics. Economics always wins. If you want to say why architecture is important, you have to cast it in economic terms.
Quailty is something i can trade-off the cost. But, quailty in software means a whole bunch of different things and ome of these things are user, manager or customer can see them but some of them they cant. Architecture is about internal quailty is not directly visible.
Internal quailty is more long-term picture.
Software architecture is important because if I buy the product thats hundred dollars cheaper and has low internal quailty, I win at the moment.
Ask yourself the following questions
Does your software system have a well defined structure?
Is everybody on the team implementing feature in a consistent way?ü
Is there a consistent level of quality across the codebase?
Is there a shared vision for how the software will be build across the team?
Does everybody on the team have necessary amount of technical guidance?
Is there an appropriate amount of technical leadership?
The benefits of software architecture in summary:
A clear vision and roadmap fot the team.
Technical leadership and better coordination.
A stimulus to talk to people in order to answer questions relating to significant decisions.
A framework for identifying and mitigating risk.
Consistency of approach and standards, leading to a well structured codebase.
A structure with which to communicate the solution at different levels of abstraction to different audiences.
Becoming a software architect isn’t something that simply happens overnight or with a promotion. Its a role, not a rank. ıts something that can be performed by a single person or shared amongst the team.
The software architecture role
Architectural Drivers:
Understanding the business goals and managing the architectural drivers which includes functional and non-functional requirements and the constraints of the environment.
Designing Software:
This is about understanding how you are going to solve the poroblems posed by the architectural drivers, creating the overall structure of the software sytem and vision for the delivery.
Technical Risks
Like good chefs, architecs should taste what they are producing. In a nutshell, this is about proactively identifying , mitigating and owning the high priority technical risks.
Architectural Evolution
Software architecture need to be taken care of. Somebody need to look after it, evolving it throughout the delivery in the face of changing requirements and feedback from team.
Coding
Coding provides a way for the architects to share the software development experience with the rest of team which in turn helps them better understand how he architecture is viewed from a development perspective
Quality Assurance
Its’s more than just doing code reviews.
You need a baseline to assure against, which could mean the introduction of standards and workinc practices of standards, design principles and tools.
QA also includes ensuring that the architecture is being implemented consistently across the team.
Developers are likely to ignore your coding experience if you aren’t programming on the project.
Building prototypes and proof of concepts related to the software system in question is a great way to be involved.
Getting involved with the code reviews is one way to at least keep your mind fresh with technology and how its being used. You could damage your reputation if you start nitcpicking or getting involved in discussions about technologies that you have no experience with.
Most of the best architects I know have come from a software development background. This doesn’t mean that they are the best coders on a team but they are able to switch between low-level details and the big picture.
Soft Skills
Leadership: is ability to create a shared vision and take people on a journey to satisfy the common goal
Communication: You can have the best ideas and vision but you are dead if you are unable to effectively communicate this to others.
Influencing: This is a key leadership skill.
Confidence: doesn’t mean arrogance.
Collobration: listening, being open minded and responsive to feedback
Coaching: you will need to coach people on their role, technologies etc.
Mentoring: is about facilitating somebody’s learning rather than telling them how to do something.
Motivation: keeping the team happy, up-beat and positive.
Facilitation: you need to step back and facilitate discussions particularly where there is a conflict withing the team.
Responsibility: You can’t necesaarily blame the rest of the software development team for failure. Its your problem if your software architecture doesn’t satisfy.
Delegation: there is a fine line between delegating everthing and doing everthing yourself.
Questions:
Do you and your team have a standard definition of what software architecture means? Could you easily explain it to new members of the team? Is this definition common across your organisation?
Can you make a list of the architectural decisions of your current project?
What’s difference between software architecture and software developer roles?
What problems is the lack of software architecture causing now and future?
Is there a risk that these problems will lead to more serious consequences (loss of reputation, business, customers, money, etc)
has something already gone wrong?
Non functional reuqirements: performance, scability, availability, failover, security, audit, resilience, internatilonalization an localization, monitoring, management, data retention and archiving, interoperability,
