|Software Architect - an introduction|
There is a tremendous amount of software being developed for an equally huge amount of reasons. Unfortunately, in this high technology, leading edge, paradigm-shifting world of computing, we have forgotten the original promise of technology. It was meant to make our lives easier.
This book is about how individuals can take the lead in realigning our development efforts to that promise. In doing so, we shall in turn take our lead from the practice of Architecture, when Architects formed themselves into organisations determined to combat the problem of buildings falling on people’s heads.
The change is already underway. The position of Software Architect, or a similar title, has been created by many organisations in the realisation that software development needs to be led by a single mind, or more accurately, by a single vision. This book will guide you to the skills you need to become a software architect and survive as one.
If, for a fleeting moment, you imagine a city built the way we build our software, it would be a city of uniform greyness. It may or may not include a water system, depending on whether or not one was asked for. Ninety percent of the buildings would remain unfinished, or would have toppled to the ground as unsalvageable waste for want of better foundations.
Traffic would flow, but only because someone had found a giant to lift cars from the end of one jam and place them at the foot of another. And as you know, the cars would rarely fit the roads. Worst of all is the unending string and continuous maintenance required to hold the buildings together.
There in the midst of this rubble, picking a way through the web, walks the hastily hired architect with a simple brief: 'Please make our rubble into the glorious living spaces we imagined.'
Before you enter the city, I should warn you, we haven't yet looked at the buildings. The doors are not where we want them, and no-one measured a person to see if they would fit in.
Now you may argue this is not quite the case, but no-one can be sure. IT failures are largely invisible to those outside the city walls.
Enter the Software Architect. The Software Architect teamed with a Business Analyst will extract, define and create a software architecture to deliver your needs. Then matched with a Project Manager, will control the technology and flow of development while the Project Manager controls the timelines and risks.
At the highest level, the Software Architect will work with the sponsor to identify architectural requirements while the Business Analyst identifies the business requirements. Together they will model the process the software must fulfil, and the means by which it will do so. The sponsor will then identify those who have input into the project, and the model grows as it moves down through the ranks. Detail is added as appropriate, and when the model is presented to development, the architectural process moves from one of vision and design to one of management.
In organisational structures, a Software Architect will begin to layer development efforts. A team of a hundred will have a Senior Software Architect, and further Software Architects who lead individual projects or manage specific areas of expertise. Senior developers will take the Software Architects' models and convert them to skeleton code for junior developers and specialists to complete.
Doing so will make development run more smoothly, be more controlled and more measurable. It is the job of the Software Architect to ensure standards are being met and that development plans are adhered to.
At present, software development teams have little hierarchical structure. Putting in place an architecturally led process will give the development teams a clearer career path and career choice. Instead of the traditional Developer, Team Leader, Development Manager, they will see Developer, Senior Developer, Software Architect, Senior Software Architect. They may choose to become Technical Specialists, or follow the more traditional path of Team Leader then Development Manager.
As more of us become Software Architects, we will begin to conform to the standards of the Software Architect community. This, in turn, will mean businesses begin to manage the processes and techniques of software development as they would manage any other discipline, from accounting to product development.
For business leaders, Software Architects will be looking over the horizon when modelling systems. We will be looking at new technologies, and the business milestones you wish to cross and hurdles you must jump to get there. It all depends what you want in your software, more hurled up skylines or more beautifully crafted cathedrals.
Figure 1.1. Joe
Meet Joe. Joe is the product of long years at the forefront of software development. One day, perhaps we will have a Joe in every organisation. For now, he is a mythical being, a shining light on the horizon towards which we might travel.
If the description of Joe overwhelms you, fear not. You will be a Software Architect long before you are Joe.
Joe is the perfect Software Architect. We can define him by who he is and what he does.
Joe is experienced. He knows the software architectures of many systems, and the design patterns used in their creation. He has used various software tools to enable him to understand and communicate his experience to others in and beyond his business. He has used many languages and is quite familiar with the techniques of object orientation and frameworks. He has been involved in creating, maintaining and using many software systems and is well aware of solutions to recurring software problems.
Joe works for a stockbroker. He understands stockbroking in mind-numbing detail, is very familiar with the whims, prejudices and needs of the senior decision makers. Indeed, he often golfs and sails with these decision makers and is considered a peer. Together they look to the glowing future of stockbrocking and how they can best grow their business with the strategic use of information technology.
None of Joe's peers understand a word he says when he's on the phone to his software buddies. He talks of singletons, proclaims one day that factories are better than brokers, then changes his mind the next. He talks of the software process, of waterfalls and spirals, of RUP, OOSP, OPEN and RM-ODP. He considers with the development teams how they might best utilise these processes and concepts in their business, and how they can best support the business process with their software process. He talks of leveraging the process to deliver outstanding software within tight timeframes, while using his time estimation skills of COCOMO and Function Point Analysis to protect the developers from overambitious schedules. In discussing process, he is aware that the architectural process is different to that of a project.
He is a technological expert. He knows the alternatives and how to compare and select new technologies. He keeps up to date with the marketplace and prides himself on knowing the emerging ideas and products in the software world.
He is an expert visualiser and expounder. He can abstract solutions to explain them to his peers, clients, other architects and development teams. He favours UML as a modelling environment, but rarely uses it for conversing with those outside development.
Joe is a nice fellow. He presents and communicates with aplomb. He is empathic, approachable, a good and keen mentor, highly credible and dedicated to his profession. When differences arise between developers, or more usually between development and management, he is a skilled negotiator, able to resolve differences so both sides appear to come off well.
He is insightful, creative, investigative, practical, visionary, and pragmatic. He sits comfortably interdependent between development and management. He is proactive, able to put first things first. He synergises, and seeks to understand before seeking to be understood.
All of this is who Joe is. He's a good egg, easy to get along with and a good oiler of seized cogs. The rest of Joe is what he does.
He delivers on the promise that technology is meant to make our lives easier. He still remembers the (retrospectively poor) predictions that computers would lead to a three day working week because there simply would not be enough work to do that could not be automated.
He is a visionary and a strong leader. He leads the architecture team, the developer community and the technical direction of the organisation. In creating the vision, he creates the architecture to back it up. When doing so, he ensures the architecture fits existing, planned and external architectures, carefully formulating designs through technological feasibility studies and efficient prototyping, while seeking to reduce architectural and project risk.
He ensures each system meets its purpose and fits the envisioned architecture by steering each project (whether architectural or not) through a defined process. He understands requirements and identifies stakeholders. He extracts, analyses and pushes back unrealistic or costly requirements, resolving ambiguities and understanding the business needs to allow him to do so.
He ensures correct implementation by asking if stakeholders, sponsors and developers are happy. He reviews project requirements, analysis, designs, timescales and project plans, code, style and test plans. Even after a project has been released, he looks for user satisfaction and reviews post release change requests.
From here to software architecture
Who needs software architects?
What does a software architect do?
The purpose of this book
Climbing the Software Architects’ mountain
With whom does a Software Architect interact?
Modelling in UML
Analysis of requirements
Iterative, incremental methods
Management and the environment
When can I have it?
The daily grind
Patterns and antipatterns
Enterprise Architecture and views
Where do we go from here?
Aardvark & Aardvark
This is a primer to help a Software Developer or Software Engineer become a Software Architect. It is intended to introduce the role of the Software Architect and the arena in which the Software Architect will operate.
There is a lot to the role. You will need to study a great deal to be an effective Software Architect. For this purpose, I have provided references for further reading. I hope it is not too daunting. You will study the arts and sciences of software architecture; you will study current and emerging technologies, the software process, organisational politics and self fulfilment.
In comparison with building, just as a draughtsman with sufficient study, skill, personal attributes and motivation can become an Architect, so too can a Software Developer, with the same study, skill, personal attributes and motivation, become a Software Architect.
The change from Software Developer to Software Architect will require you to:
You may already possess all of these skills, in which case, you can
I have invented no new ideas or methodologies. We have had enough ideas. It is time to begin implementing them. Our ideas must be about the software we are inventing, not the way we are going to invent it.
Most certainly not. There are practicing Software Architects in many software houses and organisations right now. You may be working with one.
There are also architectural groups you may wish to join in many standards based organisations. I recommend the Worldwide Institute of Software Architects, or WWISA. You can find out more at www.wwisa.org.
They are applying architectural techniques to the problems and challenges of building software products and systems. They are also upholding best practice for the software development process in a symbiotic relationship with Developers, Business Analysts and Project Managers. Architecture flourishes best in an architecturally led environment.
Software Architecture is the act of applying repetitive, measurable methods to the development of software products, whether they are systems, applications or objects. To be a Software Architect, you must study and apply the practices of Software Architecture, as both a manager and technician.
You can become proficient by following the path laid out in this book. Of course, on your way, you may look up one of the many references provided, and that will give you more ammunition and supplies to help you reach your goal. You may also decide to join us in the Worldwide Institute of Software Architects (WWISA), in creating a profession for Software Architects.
Imagine you are climbing a mountain, or if you prefer, a ladder. The ladder has eleven rungs, the mountain eleven stages. It does not matter if you think mountain or ladder as they are both models or abstractions of the real climb from developer to architect. Even climb is a metaphor, for you will not be any higher physically. Metaphors and models are what Architects use to materialise the immaterial (or to display their thoughts). Imagine away, I prefer mountains.
Our first stage will be an overview of the waterfall model, which is a simple metaphor, model or abstraction for a linear software development process. In the basic waterfall model, we go from requirements gathering to development, to test, to release, a four stage process. All of the musings of this book will be based upon a development process derived from the waterfall model, called the Unified Process for software development. We shall also discuss other development processes along the way.
We begin by stretching out our waterfall at the points of initiation and development (writing code, drawing pictures), and introducing requirements analysis and system design, which should precede writing code.
We shall then take the waterfall and make it an iterative or cyclic process.
At camp2 / rung 2, we shall take a look around at our position. Understanding the process is not enough. We must be able to model and communicate it. It is not good enough to make plans in your head, you must also sell your ideas to your peers and your superiors.
Onto the first snow slope we go, or if you’re a ladder climber, the rung you once spilled grease over which has been rather slippery since. We have to learn to model.
There are lots of ways to draw interconnected boxes. There are also a lot of drawing tools you can use to make a really nice job of it. The problem is that all of these methods are your methods. No-one else will do it your way. There is already a standard software modelling method called the Unified Modelling Language (UML). It exists and it is sufficiently detailed to model software and business systems, so why invent your own? Somewhere between camps two and three, you must give up your blob and line diagrams.
Let’s drop the ladder analogy and concentrate on our mountain. It is a better model in that the struggle is greater. Almost anyone can climb a ladder. Less than anyone will become a Software Architect.
Rest day. Let’s brew up a few mugs of tea and stare across the peaks beneath us. Each small peak could be an architectural method; we’ll take a look at a few of them.
Onward and upward. It’s time to look at how to structure your products. We’ll look at design from the point of view of the architect.
The air is getting thin, but the preparation of the earlier stages means you’re tough enough. Patterns and antipatterns, software methods copied from psychology and architecture.
Notice the use of the word copied here. You are familiar with copying and pasting so I used it. I could have written stolen or borrowed. Each term would have sufficed. But we have been calling a spade a simple entrenching tool for long enough. Let’s call it what it is for a change. People will like us better. Learn to speak from the point of view of the user.
Figure 1.2 A simple entrenching tool
Time for some map reading. But do you know how to read the map? What options do you have for mapping your software world? This is the world of architectural views.
The peak is in sight now. Time to learn how to sell your newly found architectural skills to your peers and superiors. When you’ve climbed the mountain, you will have to help others at least part way up the slope. No Software Architect can work in isolation.
Things are getting tough. It’s time for some dot combat. Life as a Software Architect is never easy. Even people from your own team will undermine you. They will rubbish your ideas. Be inclusive, invite them all in. Mentor them, listen to their ideas, and leave room for them to have some of their own. They will like you more. You will be more successful.
Art. You may be gasping for air, but take a moment to study the marvels around you. Is your development environment helping you to develop beautiful architectural solutions and interfaces? Does it use the most magnificently constructed algorithms, but look like a button and text box? What’s the point of reaching the summit with a broken camera?
Be proud, you have reached the top. All you have to do is get down and tell everyone. Some won’t believe you made it. Some think man never walked on the moon. How will you adjust to life on the ground now you’re a Software Architect? How will they know you made it?
This is your imaginary mountain. Keep it in mind as you go. The chapters of this book are arranged to help you up the mountain, but are not numbered as are the camps. If you like, this imaginary climb is one view of the architectural trail. Another view is the chapters of this book. Both look at the same thing, but from different points of view. When you are a skilled architect, you too will provide alternate views of your proposals. You may create multiple sets of views, one per client. After all, viewers are mostly interested in their own (rather limited) point of view.
The following diagram represents the interactions between individual roles on a software project. It is an example of a software house developing a bespoke business solution for a client.
Figure 1.2. Software Architect collaboration
In the following discussions, I shall be referring to the roles with whom a Software Architect will interact. Here is a whistle stop tour.
Someone who will ultimately use the deliverables of this project
The person who will pay for the project
The person who analyses the operation of the business and defines the requirements the project will fulfil
Why not you?
The person who is responsible for delivery of the project in the identified time period.
The person managing the development teams, the development environment and process, and assigning people to project teams.
The person managing a single development team on a project
The writer of code and drawer of pictures
Someone who specialises in a specific area of development
The person designing the tests used by the testers
The person responsible for ensuring all of the original requirements have been met by the results of the project, and that the deliverables are bug free.
These are the roles involved. One person may fill more than one role, or a role may be shared by a team of people. This book looks at the role of the software architect.