You are currently browsing the category archive for the ‘Architecture’ category.
I am working with an SME customer at the moment that is big enough to have a high dependency on their website but not big enough to have an operational team available feeding and watering their systems all day, every day. This type of customer is not only common in the self-service cloud, but is the hottest, and probably biggest, target market.
So we’re building an AWS based system that has been architected, from the ground up to be loosely coupled, failure resilient and scalable. We have multiple load balanced and auto-scaled web servers across multiple availability zones. We have mongoDB replica sets across multiple machines and a hot-standby RDS MySQL database. We have Chef, with all its culinary nomenclature of recipes and knife telling all the servers what to do when they wake up. We have leant towards AWS services such as S3 and SQS because of their durability instead of trying to roll our own. We have engineered the system so that even if multiple failures occur that the solution will still serve requests until the next day when someone comes in and fixes things – much like a 747 can have multiple engine failures and still operate adequately without a need to repair or replace any of the engines while in flight.
In a nutshell, we have made all the right technical and architectural decisions to ensure that things will be as automated as possible and if something goes bump in the night, that there is no need to panic.
So we were asked what would happen if something did go horribly wrong at 3am? Something not even related to OS/hardware/network failure. Something not preventable through planned maintenance like disk space or suboptimal indexes. What about something that is the result of a bug in an edge case or bad data coming in over a feed? What do you do when something happens that your automated, decoupled, resilient and generally awesome system falls over for some unknown reason?
You call the person who can fix it.
Calling an expert to look at a problem is something that happens every day (or night) in data centres around the world, whether internal enterprise or public hosting services. Someone is sitting on night shift watching a bunch of blinking lights. When a light flashes orange he sends and email or a text message. When it flashes red he picks up the phone and, according to the script and the directory in front of him, calls the person who is able to fix or diagnose the problem. Apart from the general rudeness you may get when phoning someone up at 3am, the operator making the call can do so with confidence because that person is on call and the script says that they should be notified. If they can’t get hold of someone because they can’t hear their mobile in the nightclub at 3am, the operator is not at a loss as to what to do – the script has a whole host of names of supervisors, operational managers and backup people that are, according to the script, both interruptible and keen to deal with the matter at 3am.
If you are running your system on AWS (or any similar self-service public cloud infrastructure) you don’t have a moist robot who has the scripts or abilities to call people when things go wrong. Sure, you can send a gazillion alert emails, but nobody reads their email at 3am. Even if they do see the email or text message they may think that the other people on the distribution list are going to respond – so they turn over and go back to sleep.
You would think that it there is a business out there that will do this monitoring for you out of Bangalore or somewhere else where people to do monitoring are cheap. We want cheap people to do the monitoring because, by virtue of running on AWS, we are trying to do things as cheap as possible, so cheap is good. Granted, those people doing the monitoring won’t be able to restore and database and rerun transaction logs unsupervised at 3am, but we wouldn’t want them to and neither would we want that from our traditional hosting provider (because we are cheap, remember). So if we contracted in someone for first line support we would (at least) get people who have a script, a list of contact people, telephone and a friendly demeanour.
But what would those monitoring people offer that we can’t automate? Surely if they’re not doing much application diagnosis and repair then the tasks that they perform can be automated? What you get from moist robot monitoring, that you don’t get with automated alerts, is a case managed synchronous workflow. Synchronous because you pick up the phone and if no one answers you know to go to the next step; unlike emails where you don’t know if anyone has given it any attention. Workflow is the predefined series of steps to go through for each event. And case managed gives you the sense of ownership of a problem and the responsibility to do what you can (contacting people and escalating) in order to get it resolved.
But we’re engineers who like to automate things; surely even this can be automated?
Obviously there is an engineering solution to most things in life, and the Automated First Line Support system (AFLS) would look something like this…
You need some things to measure in order to pick up if something has gone wrong. This could be simple things that we are used to from something like Amazon CloudWatch which can monitor infrastructure level problems – cpu load, memory, io etc. You can also monitor generic application metrics such as those monitored by New Relic – page response times, application errors, requests per minute, cache hits, ISS application pool memory use, database query times and, in New Relic’s case, important metrics such as the overall Apdex on the system. You will also need to build custom metrics that are coded into the system. Say, for example, the system imported data; you could measure the number of rows imported per second. You can measure the number of failed login attempts, abandoned baskets, comments added; anything really that is important to the running of the system.
Once you are collecting a whole lot of data you need to be able to do something with it. Id’ be loath to talk about a “rules engine” but you would need some DSL (Domain Specific Language) to figure out how to trigger things. It gets tricky when you consider temporality (time) and other automated tasks. Consider a trigger that looks something like this
When Apdex drops below 0.7 and user load is above mean and an additional web server has already been added and the database response times are still good and we haven’t called anybody in the last ten minutes about some other trigger and this has continued for more than five minutes, then run workflow “ThingsAreFishy”
On Duty Schedule
Before any workflow runs you need to have a handle of who (as in real people) are on duty and can be called. This could be the primary support contact person, a backup, their supervisor, the operational manager and even, if all else fails, the business owner who can drive to someone’s house and get them out of bed. The schedule has to be maintained and accurate. You don’t want a call if you are off duty. A useful feature of the schedule would also be the ability to record who received callouts so that remuneration can be sorted out.
Voice Dialler and IVR System
You would need the AFLS to be able to make calls and talk to the person (possibly very slowly at 3am) and explain what the problem is. This is fairly easy to do and products and services exist that will translate your workflow steps and messages into voice. It would also be useful to have IVR acknowledgement prompts as well “Press 1 if you can deal with the problem… Press 2 if you want me to wake up Bob instead… Press 3 if you will look at it but are too drunk to accept responsibility for what happens”
“I’m Fixing” Mode
The AFLS will need to detect when it should not be raising triggers. If you are doing a 4am Sunday deployment (as the lowest usage period) and are bouncing boxes like ping-pong balls, the last thing you want is an automaton to phone up your bosses boss and tell him that all hell is breaking loose.
Host Platform Integration
Some triggers and progress data will need to come from the provider of the platform. If there is a major event in a particular data centre all hell may be breaking loose on your system as servers fail over to another data centre. Your AFLS will need to receive a “Don’t Panic. Yet.” message from the hosting providers’ system in order to adjust your triggers accordingly. There is no point in getting out of bed if the data centres router went down for three minutes and now, five minutes later, when you are barely awake, everything is fine.
All of this needs to hang together in an easy to use workflow system and GUI that allows steps and rules to be defined for each of your triggers. The main function of the workflow is not diagnosis or recovery, but bringing together the on-duty schedule and the voice dialler to get hold of the right person. It would also be great if workflows could be shared, published and even sold in a “Flow Store” (sorry Apple, I got it first) so that a library of workflows can be built up and tweaked by people either much smarter than you are or more specialised with specific triggers that you are monitoring.
The AFLS should cost a few (hundred maybe) dollars per server per month. None of that enterprise price list stuff will do.
Like everything else that we are consuming on the public cloud, it needs to be easy to use and accessible via a web control panel.
Is anybody building one of these?
Obviously you don’t want to build something like this yourself; otherwise you land up with an Escheresque problem of not being able to monitor your monitor. Automated First Line Support (AFLS) needs to be build and operated by the public cloud providers such as Amazon, Google or Microsoft (Do you see, @jeffbarr, that I put an ‘A’ in the front so that you can claim it for Amazon). Although they may want someone from their channel to do it, you still need access to the internal system APIs to know about datacentre events taking place.
Unfortunately the likes of AWS and Google don’t have full coverage of metrics either and need something like New Relic to get the job done. Either New Relic should expose a broader API or they should get bought by Amazon; I’m for the latter because I’m a fan of both.
Regardless of who builds this, it has to be done. I’ve just picked up this idea from the aether and have only been thinking about the problem for a day or two. No doubt that somebody has given this a lot more attention than me and is getting further than a hand-wavey blog post. As the competitive market heats up, it is imperative that the mega public clouds like AWS, Azure and GAE, that traditionally don’t have monitoring services and aren’t used to dealing directly with end users do some sort of AFLS. If they don’t, the old school hosters that are getting cloudly, like Rackspace are going to have a differentiator that makes them attractive. Maybe not to technical people, but to the SME business manager who has to worry about who gets up at 3am.
I like to ride motorbikes. Currently I ride a BMW K1200S – a sports tourer that is both fast and comfortable on the road. Before that I had a five year affair with a BMW R1150GS which took me to all sorts of off-the-beaten-track destinations before we abruptly parted company with me flying through the air in one direction as my bike was smashed in the other direction by criminals in a getaway car.
Most motorbike enthusiasts have, like me, owned a few in their lifetimes and in most cases they are of differing types. A road bike, no matter how much you are prepared to spend, can barely travel faster than walking pace on a good quality dirt road because, apart from the obvious things like tyres and suspension, the geometry is all wrong. The converse is similar – a good dirt bike is frustrating, dull and downright dangerous to ride on a road.
Bikers understand the issues around suitability for purpose and compromise more than most (such as car drivers). Our lottery winning fantasies have a motorbike garage filled, not simply with classics or expense, but with a bike suitable for every purpose and occasion – track, off-road, touring, commuting, cafe racing and every other obvious niche. Some may even want a Harley Davidson for the odd occasion that one would want to ride a machine that leaks more oil than fuel it uses and one would want to travel in a perfectly straight line for 200 yards before it overheats and the rider suffers from renal damage.
But I digress. Harley Davidson hogs, fanbois (or whatever the collective noun is for Harley Davidson fans) can move on. This post has nothing to do with you.
There is nothing in the motorbike world that is analogous to the broad suitability of the SQL RDBMS. SQL spans the most simple and lightweight up to complex, powerful and expensive – with virtually every variation in between covered. It is not just motorbikes, a lot of products out there would want such broad suitability – cars, aeroplanes and buildings. SQL is in a very exclusive club of products that is solves such a broad range of the same problem, and in the case of SQL, that problem is data storage and retrieval. Also SQL seems to solve this problem in a way that the relationships between load, volume, cost, power and expense is fairly linear.
SQL’s greatest remaining strength and almost industry wide ubiquity is that it is the default choice for storing and retrieving data. If you want to store a handful of records, you might as well use a SQL database, not text files. And if you want to store and process huge amounts of transactional data, in virtually all cases, a SQL database is the best choice. So over time, as the demands and complexity of our requirements has grown, SQL has filled the gaps like sand on a windswept beach, and exclusively filled every nook and cranny.
We use SQL for mobile devices, we use SQL for maintaining state on the web, we use SQL for storing rich media, and use it to replicate data around the world. SQL has, as it has been forced to satisfy all manner of requirements, been used, abused, twisted and turned and generally made to work in all scenarios. SQL solutions have denormalization, overly complex and inefficient data models with thousands of entities, and tens of thousands of lines of unmaintainable database code. But still, surprisingly, it keeps on giving as hardware capabilities improve, vendors keep adding features and people keep learning new tricks.
But we are beginning to doubt the knee jerk implementation of SQL for every data storage problem and, at least at the fringes of its capabilities, SQL is being challenged. Whether it be developers moving away from over-use of database programming languages, cloud architects realising that SQL doesn’t scale out very well, or simply CIO’s getting fed up with buying expensive hardware and more expensive licences, the tide is turning against SQL’s dominance.
But this post is not an epitaph for SQL, or another some-or-other-technology is dead post. It is rather an acknowledgement of the role that SQL plays – a deliberate metronomic applause and standing ovation for a technology that is, finally, showing that it is not suitable for every conceivable data storage problem. It is commendable that SQL has taken us this far, but the rate at which we are creating information is exceeding the rate at which we can cheaply add power (processing, memory and I/O performance) to the single database instance.
SQL’s Achilles heel lies in its greatest strength – SQL is big on locking, serial updates and other techniques that allow it to be a bastion for consistent, reliable and accurate data. But that conservative order and robustness comes at a cost and that cost is the need for SQL to run on a single machine. Spread across multiple machines, the locking, checking, index updating and other behind the scenes steps suffer from latency issues and the end result is poor performance. Of course, we can build even better servers with lots of processors and memory or run some sort of grid computer, but then things start getting expensive – ridiculously expensive, as heavy metal vendors build boutique, custom machines that only solve today’s problem.
The scale-out issues with SQL have been known for a while by a small group of people who build really big systems. But recently the problems have moved into more general consciousness by Twitter’s fail-whale, which is largely due to data problems, and the increased interest in the cloud by developers and architects of smaller systems.
The cloud, by design, tries to make use of smaller commodity (virtualized) machines and therefore does not readily support SQL’s need for fairly heavyweight servers. So people looking at the cloud find that although there are promises that their application will port easily, are obviously asking how they bring their database into the cloud and finding a distinct lack of answers. The major database players seem to quietly ignore the cloud and don’t have cloud solutions – you don’t see DB2, Oracle or MySQL for the cloud and the only vendor giving it a go, to their credit (and possibly winning market share), is Microsoft with SQL Server. Even then, SQL Azure (the version of SQL Server that runs on Azure) has limitations, and size limitations that are indirectly related to the size of the virtual machine on which it runs.
Much is being made of approaches to get around the scale out problems of SQL and with SQL Azure in particular, discussions around a sharding approach for data. Some of my colleagues were actively discussing this and it led me to weigh in and make the following observation:
There are only two ways to solve the scale out problems of SQL Databases
1. To provide a model that adds another level of abstraction for data usage (EF, Astoria)
2. To provide a model that adds another level of abstraction for more complicated physical data storage (Madison)
In both cases you lose the “SQLness” of SQL.
It is the “SQLness” that is important here and is the most difficult thing to find the right compromise for. “SQLness” to an application developer may be easy to use database drivers and SQL syntax; to a database developer it may be the database programming language and environment; to a data modeller it may be foreign keys; to a DBA it may be the reliability and recoverability offered by transaction logs. None of the models that have been presented satisfy the perspectives of all stakeholders so it is essentially impossible to scale out SQL by the definition of what everybody thinks a SQL database is.
So the pursuit of the holy grail of a scaled out SQL database is impossible. Even if some really smart engineers and mathematicians are able to crack the problem (by their technically and academically correct definition of what a SQL database is), some DBA or developer in some IT shop somewhere is going to be pulling their hair out thinking that this new SQL doesn’t work the way it is supposed to.
What is needed is a gradual introduction of the alternatives and the education of architects as to what to use SQL for and what not to – within the same solution. Just like you don’t need to store all of your video clips in database blob fields, there are other scenarios where SQL is not the only option. Thinking about how to architect systems that run on smaller hardware, without the safety net of huge database servers, is quite challenging and is an area that we need to continuously discuss, debate and look at in more detail.
The days are the assumption that SQL will do everything for us is over and, like motorcyclists, we need to choose the right technology or else we will fall off.
I originally published ‘The Usual Suspects’ in August 2006 and at the time it seemed to strike a chord with the beginning of the anti-architect revolution. In the three intervening years the use of the ‘architect’ label has become a title that any self-respecting developer doesn’t want and is synonymous with someone is no good at software development. I thought that on the three year anniversary of the original post it was time for un update by including the architects that have emerged more recently. Also, apologies for the masculine reference to the architects – there are some women out there doing bad architecture as well.
The Hammer Architect
The Hammer Architect knows one tool reasonably well, although because he may also be a Non-Coding Architect, may only know the tool that everyone stopped using five years ago. The Hammer Architect sees every problem as a nail perfectly suited to his hammer and bangs away relentlessly like Bender in a steel drum with Paris Hilton. Hammer Architects leave behind solutions that had promise after two weeks (when the prototype was delivered) but months into the project seem not to have moved beyond the initial prototype because the wrong problem is being solved.
How to spot The Hammer Architect
Hammer Architects are closely aligned with the marketing arm of the hammer vendor and, when the project is going awry, are able to wheel in a technology specialist from the vendor’s marketing department who is able to reinvigorate the sponsors and confirm that The Hammer Architect is doing a grrrreat job. You will also find that The Hammer Architect will send you links to nicely formatted case studies on the success of his hammer as implemented in a different country, a different region, language and currency and in a different industry that apparently solves a problem completely unrelated to your own.
The Community Architect
The Community Architect thinks that his customers are impressed with his ‘Architect’ title and assumes that the technical community will also be suitably impressed. He stalks unsuspecting user groups and conferences offering to do presentations where the subject may look compelling but is delivered blandly and where the entire presentation is so lacking in anything remotely compelling that half of the audience are asleep and the other half are engrossed in their mobiles looking out for interesting tweets. The Community Architect doesn’t get much feedback and people are polite in the breaks, ushering him on his way, thankful thanks he will present next month to a different user group.
How to spot The Community Architect
The Community Architect is generally quite senior at a small ‘consulting company’ with an unremarkable name that, although on every slide, is forgotten three minutes into the presentation. A Google search of his name returns links to a guy from a country town that is suspected of beating his mother-in-law to death with a with a hosepipe and, since you can’t find any technical references, content or blog for The Community Architect, you begin to think that it is the same person. The first slide in their presentation has the word ‘Architect’ in the title and ‘Architecture’ on virtually every slide. If you stayed around long enough to collect a business card you would see that their title contains all of the following words – ‘Architect’, ‘Consultant’ and ‘Senior’.
The Non-Coding Architect
The Non-Coding Architect simply became so good at coding that he reached a spiritual coding nirvana where his mastery of code was so high, and so pure, that he had to move to another plane of coding consciousness and leave the code behind altogether. Because his code was so pure he can understand all technical problems just by reading a product announcement on the vendors’ website, watching a video and meditating. He is able to pluck the essence of the solution out of the aether, which in turn gets handed down to the unwashed developers for implementation.
How to spot the Non-Coding Architect
Non-Coding Architects are difficult to spot because they masquerade as Enterprise Architects and can even produce documentation or blog posts that give you the impression that they have written code in the last few years. The easiest way to identify a Non-Coding Architect is to invite them (in a grovelling manner of course) to help you solve a programming problem you are having – right there in the IDE. The Non-Coding Architect will not grab your keyboard and push you out of your chair, but will feign an almost solution that he needs to go and try out on his machine before he gets back to you – all while making suggestions on how to adhere to his coding standards guidelines.
The Driven Development Architect
The Driven Development (*DD) Architect has moved beyond TDD, BDD and DDD and is using the latest DD technique that ‘everybody’ (being the four subscribers to the SomethingDD Google group) is using and will radically change how we do development in the future. He has a repertoire of at least 26 DD techniques and is developing support for UDD (Unicode Driven Development) to support even more techniques. He is probably working, at this very moment, on a book and seminars called ‘Design Driven Development and Development Driven Design’ but is struggling with the approach because Eric Evans got to the ‘D’ first.
How to spot the Driven Development Architect
Driven Development architects are easy to spot because they use ‘DD’ and ‘Driven Development’ frequently in conversation, blog posts and tweets. They always seem to introduce new DD techniques based on a very advanced and new framework or approach that is documented in two unindexed blog posts and seven tweets. Driven Development architects interact with real development teams in the confidence that they are better than mere TDDers but when hanging out with other Driven Development architects they tend to fight a lot – mostly about how much better SomethingDD is than AnotherDD and who’s DD should get a particular letter of the alphabet (although unicode should improve this)
The Reluctant Architect
The Reluctant Architect is simply a good technical person that is called an architect because a) he was the most senior developer on the team when the previous architect quit or b) he was at the same pay scale for the last three years and ‘Architect’ or ‘Presales consultant’ were the only career paths available or c) his employer parades him as an ‘Architect’ in front of the customer in order to get better rates. The reluctant architect does, surprisingly, actually do architecture but simply considers it part of building solutions.
How to spot the Reluctant Architect
Reluctant Architects are difficult to spot because they don’t actually tell you that they are architects. The best way to uncover a Reluctant Architect is to look for someone that doesn’t claim to be one, does architecture and is indicated as being an architect on their business card or LinkedIn profile. They also frequently deride self-proclaimed architects in conversations and posts such as this one.
Below are the original Usual Suspects from 2006…
The PowerPoint Architect
By far the most common type of architect is The PowerPoint Architect, these kinds of architects produce the best looking architectures on paper… I mean PowerPoint. Great colours, no crossing lines and reasonably straightforward to implement… apparently. The problem with PowerPoint architects is that they are so far removed from real implementation that architectures that they propose simply won’t work. The PowerPoint Architect is generally a consultant who, just before implementation is about to start, picks up their slides and moves to the next project – leaving everyone else to implement their pretty diagrams. The PowerPoint Architect believes that software development is similar to doing animations in PowerPoint and infrastructure is about how to get your notebook connected to a data projector.
How to spot The PowerPoint Architect
The PowerPoint Architect gives him/herself away by scheduling presentations in meeting rooms and having so many slides that there is no time to go into the detail. If the meeting has more business and project representatives than technical staff, it was probably organized by The PowerPoint Architect so that technical questions seem out of place and should be ‘taken off-line’. The PowerPoint Architect has also been known to use Visio.
The Matrix Architect
Named after ‘The Architect’ in the Matrix movie series, The Matrix Architect has been there so long that he/she doesn’t know any other way. Matrix Architects leaves no room for improvement, discussion or negotiation as the architecture was written by them eons ago and has worked fine, thank you very much. Much like the scene in The Matrix Reloaded, The Matrix Architect has a personalised, well defended office and if you manage to get in, you simply have to leave by one of two doors – without getting a chance to explain yourself.
How to spot The Matrix Architect
The Matrix Architect normally has their own office and is well settled. Technical books on CORBA, Betamax and other has-been technologies are proudly displayed on the shelves. The Matrix Architect can also be spotted by their uncanny ability to work their way into meetings and throw curveball comments like “That’s just like the SGML interface that we used on DECT and in my day…”
The Embedded Architect
The Embedded Architect creates architectures that are so huge and complex that removing them is similar to taking out your own liver. Most of the time they do this for career stability or, if they come from an external organization are there to milk as much future profit out of projects as possible.
How to spot The Embedded Architect
The Embedded Architect is very difficult so spot during the embryonic stage when they are infecting the existing architecture and often once spotted it is too late. The Embedded Architect often has a team of disciples that as a group understand the entire architecture, but individually know very little. A requirement that new team members go on an induction course on the architecture is a sign that there may be an Embedded Architect somewhere within the organization.
The Hardware Vendor Architect
The Hardware Vendor Architect is actually a salesman with a reworked title. The Hardware Architect’s role is to point out the flaws in everyone else’s architecture so that they can justify why the extra hardware expense is not their fault. At Hardware Architect School, The Hardware Architect is trained in creating proprietary hardware platforms that create vendor lock-in.
How to spot The Hardware Vendor Architect
The Hardware Vendor Architect normally has a car full of pens, mouse mats and notepads emblazoned with some well-known brand which they use to assimilate the weak. They also have huge expense accounts where they can take the entire data centre to lunch occasionally. They are often heard saying things like ‘You need a 24×7 99.999999% disaster recovery site’
The Auditor Architect
We are not sure of the origins of The Auditor Architect, because they are supposed to be auditing things, not creating architectures. The Auditor Architect will always propose an architecture that uses spreadsheets for every possible system interface that requires each user to be a CA so that they can review the transactions before they are submitted (not to be confused with The Auditor Project Manager who uses spreadsheets for all documentation). Since most organizations don’t have that many CA’s, The Auditor Architect represents a firm that can provide as many CA’s as may be necessary.
How to spot The Auditor Architect
The Auditor Architect always wears a black suit, white shirt and an expensive tie in the latest fashionable colour and style. The Auditor Architect will often go to great lengths to express that they are unbiased and just want to make sure that things are done correctly. Most emails received from The Auditor Architect have spreadsheet attachments.
The Gartner Architect
The Gartner Architect has knows all the buzzwords and has all the supporting documentation. They never actually put together a workable architecture but run ongoing workshops on the likelihood of the architecture looking a particular way at some point in the next six months to five years. As soon as an architecture is established, The Gartner Architect uncovers some ‘new research’ that requires a suspension of the project while the architecture is re-evaluated. Incidentally, sometimes The Gartner Architect is known as The Meta Architect.
How to spot The Gartner Architect
The Gartner Architect always does presentations with references to some research noted on every slide and the true test of The Gartner Architect is asking for the document that is being referred to – it won’t materialize. The Gartner Architect is often accompanied by a harem of PowerPoint Architects eager to get their hands on the material. The Gartner Architect is often entertained by The Hardware Architect, provided that they represent products that are in ‘The Magic Quadrant’.
The ERP Vendor Architect
True Architects for ERP systems do exist – but they hang out somewhere else, like in Germany, and not on your particular project. There is no need for an architect on a system that if changed, self destructs within thirty seconds. The ERP Vendor Architect is actually an implementation project assistant that is billed at a high rate.
How to spot The ERP Vendor Architect
The ERP Vendor Architect almost always has a branded leather folder of some really fun training conference that they went to in some exotic location with thousands of other ERP Vendor Architects. A dead giveaway is if The ERP Vendor Architect and The Hardware Architect are exchanging corporate gift goodies – a sure sign that they are colluding do blame legacy systems for the poor performance.
The UML Architect
The UML Architect is not interested in any architecture that cannot be depicted using UML diagrams and spend a considerable amount of effort making sure that this happens. The UML Architect lives in an object bubble and has no consideration that their intended audience never learned SmallTalk.
How to spot The UML Architect
The UML Architect is easy to spot from the documents that they produce. All documents have a lot of stick-men, hang-men and and cartoon characters pointing at bubbles. The UML Architect will always be able to describe the architecture by <<stereotyping>> it as something that you will understand.
The Beta Architect
The Beta Architect insists that the current version of whatever software you are using is going to be ridiculously out of date by the time the system goes live. For that reason it is important that the development be done with the beta framework, operating system or development environment and not to worry, the product will be probably released before the system needs to go into production.
How to spot The Beta Architect
The Beta Architect normally wears a golf short with a large software vendors logo embroidered on the front and walks around with a conference bag suitably branded. The Beta Architect normally comes from an external organization that has a partnership with a large vendor indicated by some metal, but always gold or platinum – bronze and silver partners are not worthy.