Solution Design

What makes a good solution architect?


I’ve worked with quite a few over the years, from many different companies in many different sectors / verticals. You find however that the qualities of a solution architect shine through pretty obviously.  A solution architect does not have a wall full of qualifications proving then know how to ‘code in a proper way’ or ‘understand architectural patterns’ as this proves nothing to the business.  When it comes to someone directing how a suite of business requirements is translated into a solid business solution there is no substitute for experience and experience is full of failure.

In my view , a solution architect must understand the business and the technical side of things. In a broad way. I know of one or two ‘Solution Architects’ that have just spent time looking after computer networks for 10 years and I really feel that this is in no way a path to becoming an architect.  The architect must understand the business first and foremost but have experience in more than one specific area of technology, but have expertise in at least one.  For me, that would translate into experience into:

– Network Infrastructure : It’s important that an architect knows how the network hangs together. How machines communicate each other and be able to use the most common OS command line / shell tools to work on remote servers and detect problems on the network.  Network security is also important, as are topics such as certificates and encryption. Finally, an architect should be familiar with the OSI model and the communication protocols that operate at each layer of the stack.

– Server Technologies : An architect should have a relatively good understanding of core server roles and the services and features they provide to clients. DNS and DHCP for example are basic server features that almost all servers of differing operating systems will have and need configuring. Some experience in servers such as Windows Server, if you are working in a Microsoft dominated network environment are also a must. Understanding active directory, network secure-able objects (users/computers etc), domain group policy and NTFS permissions are basic features that one should be aware of.

– Database Administration or Design : Almost all applications that a solution architect will work with will have a persistent data store and that is a database for the majority of the time. Therefore understanding SQL is a no-brainer. You simply cannot call yourself a solution architect if you don’t know how to SELECT from an INNER JOIN. Database servers are generally under utilized in a big way (at least that’s my experience working with SQL Server for 10 years).  SQL Server for example comes with several major ‘components’ for reporting, analysis, notifications,data extraction and loading and of course the core database. Many developers only know how to use the database feature and get stuck when it comes to the SQL Server security model.  I have not met a developer yet who understands all of the database roles and what features they provide.  Finally, a good solution architect know’s when logic should be placed in stored procedures and when it should be placed in the business logic tier.  A major bug bare of mine is large stored procedures that do more than basic data manipulation and organization.  In summary, understanding what data layer support you have when architecting an application is key so you can properly place component responsibility within the data layer.

– Software Design & Development : Yes, that means that as an architect, you should have experience not just writing code, but designing applications and seeing those designs through the entire first cycle.  This means that from a set of business requirements, you understand the technical landscape (see above) enough to present to the business a preliminary, high level design by taking the ‘what’ of the functional and non functional requirements and turning those into the ‘how’ in terms of high level implementation and software sub-systems.  That means identification of the technology stack to use (hence the server/network/database knowledge requirements) and what are the main high level areas of concern (including cross cutting, such as security). The architect must also determine what operational requirements should be taken into account, what architectural patterns will be used in the solution and finally how the solution will honour a set of quality attributes (maintainable, secure, extensible, scalable etc). Once the high level specification is signed off, the architect should then be able to take the high level design and move down to the implementation detail by decomposing an existing system or set of requirements into the individual software components and create a domain model.  These components should then (ideally) conform to the 3 P’s of software design, Principles, Practices and Patterns in their design and interaction.  In summary, whilst it’s important to know your code syntax and the common objects available in the libraries as part of development frameworks, you must be familiar with the principles and methods of designing good components that interact well.

So to re-iterate. These are the qualities and skills that I personally believe all good solution architects I have met have. I am certainly no barometer for assessing the role, but have worked with enough competent architects to know what skills are important and almost all of them do not hold a lot of qualifications in the technical subjects.

Experience and a strategic/practical/pragmatic skill set are far more important in reality.

To conceptualize, abstract reality, direct a solution’s development, look at every problem with the architecture in mind, provide the why, what and how in any task arising from the development project and support the developers are skills that an architect should hold.

My personal favourite skill observed however is the modesty of some architects.  When you sit in a meeting with them, you realize their experience and that they are truly the guru of the business domain, they have a constant want for knowledge and that shows in their modest approach. They clearly know more than they show and that, to be is one of the greatest qualities an architect can have.

As always, I welcome and appreciate reader opinions on the subject.

Advertisements

Transactional Isolation


Transactional isolation is usually implemented by locking whatever resource is being accessed (db table for example) during a transaction thus isolating the resource from other transactions.  There are two different types transactional locking: Pessimistic locking and optimistic locking:
Pessimistic Locking : With pessimistic locking, a resource being accessed is essentially locked from the time it is first accessed in a transaction until the transaction completes, making the resource unusable by any other transactions during that time. If competing transactions simply need to read the resourceonly (a SELECT of a data row for example) then an exclusive lock may be overkill. The lock exists until the transaction has either been committed or rolled back at which point, the resource is made available again for other transactions.
Optimistic Locking : Optimistic locking works a little differently.A resource being accessed isn’t locked when first used, but the state of the resource is noted.  This allows other transactions to concurrently access to the resource and the possibility of conflicting changes is possible. At commit time, when the resource is about to be updated to persistent storage, the state of the resource is read from storage again and compared to the state previously noted when the resource was first accessed. If the two states differ, a conflicting update was made, and the transaction will roll back.

Understanding Multi-tenancy


I’m doing a lot of research and practical ‘playing’ with the Cordys BOP 4 environment at the moment.  It’s a relatively young product from a young company (founded in 2001) but from what I have understood about the product and its architecture it is a strong, versatile collaborative tool that really supports rapid application development and maintenance for business change thus reducing general cost of ownership.  I don’t want to talk about the product itself, I will be doing that soon enough, but I wanted to cover one of the software’s best features in my opinion and that is its ability to operate within the enterprise and in the cloud utilizing a fully multi-tenant architecture.

Multi-tenancy is an architectural principle which says that a single install of a software program / server application can service multiple client ‘organizations’, providing a customized isolated application environment with its own data.  This is in complete contrast to the idea of multiple instances for each organization (i.e. installing an instance of some server software and underlying database to serve one organization and store only that organizations data).  Each ‘organization’ (in the general sense of the word) is classed as a tenant, using the application, therefore if one single installed application can serve multiple tenants their customized view of the application, then it is said to have multi-tenancy (supports multiple tenants). Google apps is a perfect example of a multi-tenant architecture.  Multi-tenancy is the foundation architecture for most if not all Software as a Service applications, thus cloud applications support multi-tenancy.

How multi-tenancy is implemented in an application can vary from application to application.  The general principle however is to have the application virtually partition portions of its data and services to different consuming organizations.  A very simple example at the data level would be to have the application generate a set of related data tables under new database schemas as new organizations are set-up to use the application (so a schema per organization).  This separates off the data into logical groups that have their own security context on the database.  There are other ways to partition the data, but this is just to illustrate one potential method.

So multi-tenancy is a software architecture and one that is prevalent in cloud applications.  Cordys BOP 4 does this very well and I’m looking forward to investigating this product and its virtualization capabilities further.

.NET Architecture Guide v2.0


I was quite pleased this morning to stumble across a link to a document I’d read a few years ago that I remember being one of the best .NET focused guides on how to architect .NET applications and services. The document was called ‘Application Architecture for .NET – Designing Applications and Services’ and was (and still is) available to download for free in PDF format from the Microsoft website.  I remember the book being a very informative look at .NET architecture patterns for local and distributed applications / services build with .NET 1.0 but when I recently went googling for some up to date material specific to .NET 2.0 +, I learnt that there didn’t appear to be an updated version of the document available for download… until I came across Tom Hollander’s blog post.

Tom mentions that the project to update the original document was put on hold for a while, but in 2009 a v2 of it was released and is now also available for download.  The new(est) version is much bigger and expands on a lot of the original material as well as discussing the advancements in .NET features and how they support recommended architectures.

I strongly advise any developer (whether in the market as a budding architect or not) to read this guide, it’s an amazing resource for understanding .NET centric design architectures and the best part… it’s free.

Scalability, Extensibility or Maintainability


I’m currently trying to make my way back to Holland right now after being snowed in yesterday in East England and having to deal with flight cancellations from Norwich and London.  During this time, I’ve been thinking about a project I’m currently involved in and how due to a very high level functional spec and a technical spec that really lacked a solid architectural plan, it is becoming more complex and in my opinion is starting to mould into a solution that could potentially be difficult to support.

The functional spec for this project was based on some very high level use cases and although the spec is what the project team use as a functionality reference, the use cases provided where very general and contribute to the lack of process detail in the functional spec.  Because of this, the technical spec lacks any kind of detail, there are very little Class diagrams to show the component objects, no sequence diagrams to illustrate object interaction and just a general lack of visual notation to illustrate and explain how the solution was to be implemented.  That said, the high level proposed architecture was very good and has lended well to the system at its current point in development (but hey, I’m a little biased on this front).

So back to my travel situtation.  I managed to get myself onto an overnight ferry from Harwich in the South East of England to the Hook of Holland in the Netherlands (the Hoek van Holland as it’s known to the locals).  I’m currently killing time waiting for departure and thoughts wonder over to the important aspects of systems design and the creation of a solid and sufficiently detailed solution document.  Further to this, I got thinking about what is THE most important design consideration (apart from the obvious delivery) to take into account in terms of a solutions Scalability (how a proposed solution scales up and out), Extensibility (how easy it is to extend / develop further) and Maintainability (how easy it becomes to support the system and maintain the code in a finished product).

Personally I think Maintainability is the most important.  Why?, because if the architecture is designed and the code is written with maintainability in mind, the resulting solution should not only be easier to maintain and support, but is clean of the tweaks and hacks that creep into projects as bugs are fixed and change requests are satisfied (new code which falls outside of the original vision and design).

If it is a clean system in terms of  code, then it should be an easy job to extend its functionality and scale that functionality.  Surely.  Anyone, with opposing views, please do comment, I’d love to hear alternative takes on this.

… Time to board 😉