There is a point where you start spending more time thinking on how you will build something than actually building it. You start thinking on what can you take out of your software instead of what can you put in. You realize that the only way to succeed today is to aim for the perfect simplicity. Although simplicity may sound easy, elegant simplicity is the most challenging goal in the software industry. If you are there you’ve passed the point of no return where you become an architect.
Although I have been on the role for a couple of years, and I had the basic skills associated with architecture only recently I have gone across that point and things look a lot more clear today. It’s a jungle out there.
Some believe that building software has become easier because technology has evolved, they could not be farther from the truth, building software has never been so hard, the timelines have never been so short and the basic requirements have never been so complex.
Shared identity, devices as in BYOD, form factors, usability, multi-tenancy, scalability, resilience are just a few of the attributes that users have been thought to take as normal, granted, part of any software that goes in the browser. Traditional software, at least the trend, had one, two, certainly not all. So how do you achieve it and still meet that weekly cycle?
Well the good news is that it doesn’t take a lot of code, only the right code and building on top of the right tools; it’s about how deeply you understand the problems, the protocols and the frameworks and how you put that knowledge in place to make it as simple as humanly possible and still make it great.
One example, I recently had to build an OAuth 2.0 server followed by an ASP.NET WebApi AuthorizationFilter to check the authorization token issued by that server. One print page of lines of code, weeks of reading to learn the protocol, to understand how claims can be used to simplicity the identity problems, how the token is digitally signed and how do you validate that signature, what can you do with OAuth 2.0, what does it enable, how can you extend it to go beyond what common OAuth providers do, and so one. It’s quite simple now because I have gone to the process of making it simple, a very hard process. If had just designed a custom solution, the best designed custom solution, it would have taken longer and it would be much less useful. An architect must embrace the pain of being ignorant about most of the things, and deal with it.
To finalize another example, also recently I have been working on applying different system metaphors (the list of parts you need to code to build a feature) to web development using .NET, trying to find one that isn’t just an hack that no one can evolve in the long run, but also that keeps the rate one screen one day (my goal for now). I really know how to build it with all the layers, make it SOLID, make it unit testable, as well designed as you can dream of but it breaks the one day goal, and no design is good if it doesn’t fit on the budget. I have finally made it, and guess what, it scales really well, I just have to tell my coworker what is the best example to follow and he can just add a new view in html with the bindings in place, a new viewmodel with those Knockout observables in place, a resource model, an api controller, a domain model, the repository, and a new property on the DbContext and it just works. If more coworkers are available they can repeat the steps and we can move really fast, it will have a balanced architecture, not to complex, not just an hack and you can make it move a little bit faster by adding more hands to the job. If I had a part to the metaphor I lose the productivity and if I take one out than it gets harder to test and to meet all the non-functional requirements, it’s a balance. In the end this is more about architecture then just the design or the protocols.
