by pizzathehut

3 Evil Opinions of Enterprise Architecture

I have long been an advocate of Enterprise Architecture as a concept, and have successfully helped roll out various forms of EA across different companies. However one constant has always been that EA needed to be redefined to address the widely varying views of what it was, and what benefits it could provide. In some cases this extended to changing or repairing some existing negative views. Those views could be because of one person (the architect that team or individual worked with), or as an opinion of the whole EA process.

This post shares some of those negative views, with the aim of helping architects understanding what stakeholders might think of EA and how to address them. It also allows me to be a bit negative towards EA, as I have certainly seen implementations of EA that are more a hindrance than help. As I’m currently helping roll out EA with a new company, I also want to make sure I don’t fall foul of the below perceptions.

The Government

One very common, and not entirely unjustified view, is that EA isthe remit of failed engineers or simply tech academia (e.g. those that can’t do, teach). It imposes frameworks and governance that only serve to centralise decision making and slow down the velocity of change and progress. This view can even sometimes come from architects themselves, especially Solutions Architects used to more agile processes, who would often be frustrated while waiting on their next ten minute opportunity within the bi-weekly Architecture Board to discuss their proposal for the replatforming of an entire system (or something like that). I see this view perpetrated by the more bureaucratic organisations where phrases like ‘we are not a tech company’ are prevalent (by the way, that’s probably the phrase I fear the most in any company I have worked for). In those types of companies, EA serves exactly that purpose, to slow things down, and provide assurances and accountability into any IT change. This in my opinion is the worst use of EA, and tarnishes it’s goals for others.

Rectifying this view comes down to collaboration with engineers, and building credibility with technical teams. This may also involve reviewing processes and relaxing the governance somewhat to ensure EA is guiding and not hindering development. From the business side it may also be necessary to begin demonstrating real business value quickly, and re-communicating the role of EA, along with any strategy or vision.

The Consultant

Another view of EA is the consultant view, in which architects only come into a project at certain times, spout advice and guidance, and then disappear until the end, or when something goes wrong. This view sees the architect as a bit of the ivory tower type, supercilious and not connected (or possibly experienced) with real projects. This view often stems from when actual consultants have been used to rollout EA, and their methods have been adopted by permanent replacements. This can also sometimes be the case when architects are simply stretched too thin, and can only spare time up front according to business priorities.

If you find this is the case in your practice, then consider who you have available to perform the role of Solutions s Architect within each team. this doesn’t always have to be a dedicated role, and often a lead engineer can perform this function well. Using these guys will help delegation, and also gains more buy in from engineering teams. Ultimately if you find you aren’t adding anything to a project, then simply refocus on priorities until you demonstrate the benefit that allows you the budget to get more architects.

The Thinker

Perhaps more of a character portrait, but this is certainly the view I have held myself of certain architects I’ve worked with (and unfortunately reported to). These architects tend to enjoy the blue sky thinking involved in architecture, and are typically the ones designing new processes, new templates, new acronyms, and have very little input into detail. Ideas coming from these guys tend to be quite ideological and seldom have any indication of how these visions and ideas might be achieved, at least not in any detail.

One simple solution to this one, start delivering real value. Architects need to resist the temptation to perfect everything they are doing upfront, and instead learn to be more agile and responsive. designs can change along the way, and often will. As George Patton once said;

“A good plan violently executed now is better than a perfect plan executed next week”

So how do I fix it?

All of these views derive from EA practices that have been poorly implemented, or have been implemented as top level governance frameworks with little connection to engineering and delivery. if you are in these positions, or perhaps are now implementing EA at your company, then keep these things in mind;

  • Although EA is about making IT align with business, the engineering teams are a critical part of this delivery, and their ability to deliver should be a key consideration.
  • As with all areas of business, EA needs to be seen to deliver value. In my opinion it is unacceptable for architects to spend a year in a dark room and then emerge with a radical framework designed for global dominance. Ensure you start delivering from day one, and resist overthinking or perfecting everything.
  • Although architects should be key resources and leaders of technical knowledge, don’t become the only guy with the knowledge. Ensure you have good knowledge management processes (thing Brown bag lunches , coding dojos etc), as it will upskill everyone and lighten your own workload.
  • Use diagrams as temporary tools to demonstrate thinking, and not as a governance tool to indicate an agreed design. Things change quickly in development, and adhering to thinking at the beginning of a project is dangerous. At minimum, you will find these diagrams become quickly out of date and will dilute your process. Diagrams can be given to agree an ‘approach’, and then architects should work closely engineering to ensure the final output is true to the ‘approach’, if not the actual design.
by pizzathehut

Why are you moving to the cloud?

It is becoming more and more normal for companies to consider the cloud for their hosting requirements, in particular where new builds are concerned. The advantages of cloud hosting are now well known, and it is no longer a bleeding edge technology, but something that is providing real value to business of all sizes.

Some of the inertia behind the cloud seems to be driven from a perspective of cost, in particular there is a perception that running in the cloud is cheaper than on premise. I have been involved with many architectures (both new and old) that have moved to the cloud, and a good majority of these have been driven from a cost perspective. This idea, coupled with a lack of knowledge of how to manage a cloud infrastructure and to utilise its benefits, is actually driving cost of hosting up, as well as affecting performance and stability. I have long been preaching the necessity to understand exactly how the cloud works, and some of the recommended practices or culture changes required when moving to the cloud, and I thought it was about time I put these out to the wider world.

Time to Scale

Most cloud providers offer auto-scaling functionality to allow you to deal with peaks in demand. This is a critical factor for ensuring performance, and one of the best parts about cloud hosting. The other often missed part, is scaling down. This is also crucial, as it optimises the cost of your hosting and ensures you really do only pay for what you need. You should think out clearly your scaling strategy alongside your architecture to ensure you have every part of your architecture ready. Scaling should cover both vertical and horizontal scaling as well, not just horizontal. This is particularly applicable for Platform as a Service (PaaS) services, which offer differing tiers, and tend to hold you ransom for higher performance tiers.

Ideally you should have a view of your traffic profiles over time and adjust your auto scaling factors to account for these. For instance, on weekdays you might scale between x and y for web servers, but on the weekends, you might scale between y and z. Likewise for your horizontal scaling. Scaling is not a golden bullet either, and you should consider the following when planning your scaling strategy;

  • Scaling isn’t ‘instant’ in most cases, and can sometimes take minutes to hours. If you know you have spikes at certain times, then scale beforehand
  • Scaling any 3rd party software may have licensing impacts, so beware
  • Consider all elements of your architecture when setting scaling parameters. There is no point in scaling out to 30 web servers if you will just create a bottleneck on one database server
  • Consider Infrastructure Automation tools like Salt and Chef to help create advanced scaling rules, as well as managing the auxiliary services impacted by scaling
  • Scaling should not replace capacity planning. Scaling is to optimise cost and cope with spikes in demand, and should be built on top of a well-planned architecture

Stability

When moving to the cloud, I often see companies with a perception of outsourcing networking and infrastructure knowledge. It’s true that the benefit of cloud hosting is that you no longer have to worry about infrastructure and networking, but you need to understand this, and in particular understand how your cloud hosting provider deals with it, in order to design stable systems. Graceful degredation, dependency failures etc don’t disappear in the cloud, but they can be abstracted if you don’t fully understand how your hosting provider presents these issues. This can lead to architectures that don’t take into account failure scenarios that they perhaps would have in on premise architectures. Stability is a huge issue in the cloud, and one that you should be thinking about from day one. If you are migrating an existing on premise architecture, then this is doubly important as you should not be expecting the same levels of stability, and should be planning how your architecture will cope with multiple service failures (which is a fact of cloud life).

I often see the clouds inherent instability as an advantage, as it forces you to think about resiliency and failover from day one, which only serves to increase overall stability in the application. However I often see people disregarding this aspect, instead relying on underlying cloud provider SLA’s and good old backups. Stability in the cloud basically means ‘anything can happen’, and it usually does. Services will frequently fail, contention on resources will affect performance, servers are self-healed, demand spikes add resource contention etc etc. This requires you to really consider this when deploying, and try to eliminate all single points of failure and have failover plans in place for all parts of the architecture.

Testing is a critical part of deploying to cloud, and should involve some level of failure testing. This would typically involve testing how your architecture handles under load when certain services fail. If you are on AWS, then Netflix’s Chaos Monkey (part of the Simian Army toolset) will help you introduce this type of testing, as well as giving you the rare privilege of yelling ‘Release the Monkeys!’ every time you deploy.

Culture, DevOps, and Tooling

Taking full advantage of the cloud will almost certainly require a change in culture, as well as the addition of new tooling into your architecture and deployment processes. Your culture should acknowledge and embrace the instability in cloud, through the following (as a minimum);

  • Developers should be ‘coding defensively’
  • Architects should be architecting for new failure scenarios
  • Load testing should be the norm
  • Monitoring and Alerting tools should be implemented from day one
  • Self-healing infrastructure should become the norm
  • Infrastructure automation should be utilised
  • Service failure testing (testing failure of different elements within the architecture)

Without adopting these practices then the potential for falling foul to the traps of cloud will become more likely, and frankly the benefits of moving to the cloud will be lost.

Developers and DevOps should also be utilising the on-demand nature of cloud to provide instant test servers, trying out new products and services, and continually improving all aspects of infrastructure. One common example is UI testing, which historically can prove to be a bit flaky. When running something like Selenium on your build server, there is a potential for lots of hanging browsers, which over time will impact the build server. To rectify this, you can instead put up an on-demand server specifically to run UI tests, and then shut it down once complete. While this might affect build time, it does increase stability of the overall process. This method can be expanded to add new build agents as desired to cope with load testing etc. The underlying message is that the culture of the team should adapt to take advantage of what becomes available through cloud hosting.

Performance

If any has ever told you that the cloud is fast, then you have every justification to strap them to a chair and force them to endure endless reruns of Frozen – Singalong edition while eating Rum and Raisin ice cream, a fate worse than enduring any Vogon poetry for sure. Of course the cloud can be fast if architected correctly, but compared to physical dedicated hardware….not likely.  So If you are thinking of a ‘lift and shift’ approach to your infrastructure to migrate to the cloud, this should be an immediate red flag to you and any architect involved. Hosting on-premise with dedicated hardware is an entirely different beast to hosting in the cloud. Where you might think it is a simple matter of having the same number of VM’s, this really isn’t the case, and will certainly cost you more as well as be unlikely to offer the same level of performance.

Performance from the cloud comes with the use of the available services, as well as the aforementioned scaling ability. Things like Content Delivery Networks, SSD storage etc are all likely part of your cloud provider, and so should be utilised to enhance performance.

These are some of the things that I have often seen forgotten when thinking of cloud hosting, and it’s always to the detriment of the solution.

Let me know your experiences of moving to the cloud, and in particular which things are often overlooked.

Taxonomy
by pizzathehut

Sitecore 8 Marketing Taxonomies

The release of Sitecore 8 has seen a slurry of new features and capabilities added to the new platform, all of which shine for attention. Features like the Federated Experience Manager, new Analytics Suite, Test Everything approach, and test gamification all add to the marketers arsenal of tools.

However with all these new features, some of the more subtle important changes may have been overlooked. This post looks at one of those, namely the addition of new marketing taxonomies and the new ‘Outcomes’ feature.

Taxonomy (from Greek taxis meaning arrangement or division and nomos meaning law) is the science of classification according to a pre-determined system, with the resulting catalog used to provide a conceptual framework for discussion, analysis, or information retrieval

It’s easy for us developers to often think marketers only run one or two campaigns at a time, making them easy to manage. The reality though is that marketers are often running lots of campaigns, all spanning different channels and audiences, each needing to be reported on. Prior to Sitecore 8, marketers could include a ‘type’ whenadding new campaigns, however this was a free text field and wasn’t particularly useful in reality. Campaigns were also attributed a ‘Traffic Type’, which held the method by which a user visited the campaign (direct, via branded keyword etc). Again this was useful, but relatively limited.

Sitecore 8 introduces a slew of new taxonomy methods to help categorise and manage campaigns. These are found under the Marketing Control Panel (formerly Marketing Center).

Overall

Campaign Group

A Campaign Group provides the ability to group campaigns into relevant groups, which provides the ability to report on performance of a group of campaigns under a particular umbrella. For instance, if you are running multiple campaigns around a particular event, such as ‘Digital Trendspot’, then you can attribute all the relevant campaigns into a ‘Digital Trendspot’ Campaign Group.

Campaign Group

Warn

Channel

Channel is a direct replacement for the ‘Traffic Type’ attribute in previous Sitecore versions, however it adds more flexibility over Traffic Types.  Expanding the list of Channels will show you an exhaustive prepopulated list, covering both online, and crucially, offline channels as well.

Channels

As before, new campaigns can be attributed to a channel, which denotes the expected channel that the user will visit the campaign on. Of course, a campaign earmarked for a banner ad or ad network, could feasibly be tweeted and so also drive some traffic from Social networks. To capture this, Sitecore will capture both the intended channel (i.e. the channel attributed  to the campaign), and the actual channel for the user. Using these two fields, marketers can then see how campaigns are communicated through other channels than the originally intended channel.

Assets

A Marketing Asset is typically any marketing content that is used to educate and create interest for a company’s product or services (look out for my forthcoming blog post around terminology differences between marketers and developers). These usually take the form of white paper downloads or pdf’s, could be anything the marketer wishes to use.

Assets

Sitecore 8 now provides the ability to explicitly add marketing assets and attribute them to campaigns. The Asset taxonomy follows the Campaign Groups taxonomy, in that you can create an Asset Group containing many assets. For instance, and Asset Group might be FAQ’s around your products or services, which will then contain the actual FAQ assets.

Campaign, Asset, and Goal Facets

One of my very favourite things about Sitecore is it’s absolute extensibility and flexibility. No one platform can ever provide every feature requirement of a business, and Sitecore recognises this by providing all the mechanisms necessary to easily add your own features and content, all leveraging the underlying capabilities of the platform. Facets extend this idea into the marketing realm, and are essentially there to provide further means to categorise campaigns, Goals, and Assets by ways applicable to your business.

Facets

To use these, you simply rename the applicable facet to whatever you need, and then select it in the applicable field within your Campaign, Goal, or Asset. For instance, you might require Campaign Facets that denotes a Cost Centre. To do this, unprotect one of the ‘Campaing Facet’ items and rename to ‘EMEA’. Then select your campaign and under ‘Campaign Facet 1’ (or applicable number), choose your new Campaign Facet.

Outcomes

Lastly, Sitecore 8 has added a new way to group goals, or provide a hierarchy to user actions, through the ‘Outcomes’ feature. Outcomes are intended to specify a final outcome for the visitor, which may consist of many goals before achieving that outcome. For instance, a user purchase may be an outcome. To purchase a product, a user may trigger several goals along the path.

Outcomes

Using Outcomes will give more ways to analyse traffic (and/or base personalisation on) through tools such as the Path Analyzer and Experience Analytics.