Significant licensing changes in SQL Server 2014

Thanks to Mary Jo Foley of ZDNet’s tweet earlier (@maryjofoley) I’ve just read the SQL Server 2014 Licensing Datasheet and confirmed there’s two significant licensing changes for SQL Server 2014.


More memory in standard edition

Although we rarely see standard edition used in tier-1 deployments now, in SQL Server 2014 the database engine can support 128GB of memory.  This is an increase from 64GB, that was often seen as too low a ceiling for modern deployments – although we could discuss whether that’s right or wrong for several hours.


High availability deployments now require Software Assurance

This change sneaked in but it’s there in the licensing data sheet.  For now I’m just going to draw your attention to it and let the community digest.

Licensing for High Availability

SQL Server software can be configured so that if one server fails, its processing will be picked up, recovered and continued by another server. Beginning with SQL Server 2014, each active server licensed with SA coverage allows the installation of a single passive server used for fail-over support.

  • The passive secondary server used for failover support does not need to be separately licensed for SQL Server as long as it is truly passive. If it is serving data, such as reports to clients running active SQL Server workloads, or performing any “work” such as additional backups  from secondary servers, then it must be licensed for SQL Server.
  • The active server license (s) must be covered with SA, and allow for one passive secondary SQL Server, with up to the same amount of compute as the licensed active server, only.  

You can download the licensing guide (it’s only a 3 page document) from here.

How to be a better architect – what should I do? Part 2/2



This follows part 1 of this article available here.  I recommend reading them in order!

In part 2 , I look at what initial steps you can make in your career journey from “technical solution designer” to “IT architect”.


Phase 1 – Looking at what you already do in another way

How you already work can probably be formally defined as a technology agnostic framework using architecture terminology.  Unless you’ve become familiar with architecture terminology you may not appreciate the structure and rigour around what you hopefully do already. 

For example, I didn’t realise my design methodology used waterfall principles for years after I’d started using it. And , once I’d read ISO42010, I started to see my architecture reports contained views using viewpoints.  

Despite this “what you’re doing already is a good start” phase, a lot of people feel the need to replace how they work today with a formally defined enterprise architecture framework as that will improve how they work.

The reality probably is that how you work today is probably the best way for you to be working….for now, you just haven’t formally defined how you work before.

Once how you work is defined and documented – even just in diagrams created in Visio, you can then look at the gaps, weak points and areas to optimise.  For example, is most of your effort spent in the solution design phase but little in mapping design decisions to a specific business requirement – or do you skip the business requirements analysis phase altogether?

Finally, once you have how you work documented in IT architect terminology, you can describe how you work to another IT architect in a universal language you both understand.


Phase 1 Resources

Everyone has their own preferred books and articles that help them, but these are mine relevant to this phase:

12 Essential Skills for Software Architects

Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

Design, Build, Run: Applied Practices and Principles for Production Ready Software Development



Phase 2 – Changing the purpose of your solutions


The second phase I’m going to discuss is one of the hardest I went through in my transition to becoming an IT architect – respecting the fact that very few outside of the IT department have any interest in anything technical. 

The best quote that helps me remember this was someone telling me “The only person who cares about downtime is the person who pays the electricity bill.”  The only thing anyone outside of IT cares about is business outcomes and business metrics – orders per hour, £revenue per hour, website registrations per day, profitability, costs etc. 

You may start to say you have no idea how much money your system generates, how much operating your system costs, but that doesn’t mean you can’t talk about the impact your system has on business outcomes.

By the way, I’m not suggesting you change what your solutions do – just how you describe them to new audiences.


Elevator with the CEO question

If you’re in the elevator with the CEO for 20 seconds and he asks you what you do say

a) I’m designing some software to connect our web and ordering systems

b) I’m one of your IT architects

c) I help us use technology to sell more clothing

The answer jumps out at us when we read the three options, but did the same answer flow naturally out of your mind?  Of course, you shouldn’t give the same answer to everyone in your organisation, but you can start to see the change in thinking when you describe what you do to people outside of IT.

The same approach needs to be taken when we consider what the goals of our solutions are.  Could you describe anything you’ve done recently as:

  • enabling existing product digitalisation by integrating with social media
  • increasing IT’s agility by using cloud services
  • reducing operating costs through consolidation or standardisation

Those three statements might sound non-specific to you, but they’re messages that your boss and your boss’s boss will be glad to hear as they will help everyone to understand how you’re helping the business grow, not just keeping the same old wheels turning.


Phase 2 Resources

Finally, I’m going to share two useful books that helped me transition this phase, I hope they’re useful to you too:

Real Business of IT: How CIOs Create and Communicate Value

Financial Intelligence for IT Professionals: What You Really Need to Know About the Numbers





How to be a better architect – what should I do? Part 1 of 2


Recently, I’ve been asked by several people about how to develop their IT architect skills further as they transition from being a “technical consultant” or “technical solution designer” into more formal IT architect roles.  Hopefully my own views in this article will help people when looking for that guidance.


It’s different to learning another technology or just another skill

With technical subjects, it’s mostly the case that you can read a book containing facts, start using those facts, and how you then use them is either right or wrong.  Although there’s some leeway for misinterpretation, ultimately technical things work or they don’t.

With IT architect skills, you need to take an education and experienced based approach to achieving what you want to achieve but you’ll do it your own way that suits the environment you’re in.  One person’s perfect way can be the most un-suitable for another etc.  That’s why when you take senior IT architect certifications, you have interview boards rather than exams as the best way of working is sometimes contextual.


That annoying gap between “technical designer” and “enterprise architect”

When you start searching for IT architect resources, like me you’ll probably start to realise most books, presentations, blog posts and guidance drop into one of two buckets:

  • Technical solution designer – someone who makes a combination of technology components meet functional and non-functional requirements yet has no need to explain the solution’s benefit in non-technical terms to non-technical leadership.  At this stage of solution design, business metrics such as revenue, costs, margins and profitability are rarely discussed.


  • Enterprise architect – someone who helps a business achieve its organisational goals through the use of technology and business processes – and who’s audience is typically the organisation or business unit’s executive leadership.  At this stage of solution design, justification for any solution is all about business metrics and business outcomes.



      By the way, if you now realise you work in an organisation where “enterprise architects” design only technical solutions that involve systems of systems or large numbers of servers I recommend reading the Open Group’s definitions available here.  It’ll help you understand for example how using Twitter Direct Messages to sell your company’s services is a big consideration for some EA’s right now. 

      Education for Technical Solution Designers

      As technical solution designers we were used to learning how infrastructure components, software code or software products are implemented successfully.  Typically, a solution couldn’t be considered complete until all of its components were working and users got the results they expected.

      The education resources for this area are mainly vendor training courses and academic guidance based on software engineering.  As we can all probably testify, for this stage of career development, these resources are fairly effective.


      Education for Enterprise Architects

      With our other example enterprise architects, you’ll start to find mention of formal enterprise architecture frameworks.  These allow an organisation to manage its business transformation and have names such as TOGAF, DoDAF and PEAF. 

      These are usually only seen in large organisations or projects wanting to implement an end-to-end framework for many architects that need to co-ordinate their activities.  They need something that has been validated time and time again and is suitable to manage critical business changes in large organisations.  However, they can struggle to scale downwards to small teams traditionally focussed on deploying technology solutions.  Even worse, they can be overwhelming for individuals looking for their first formal architect training.


      So what fills that gap?

      I like to think of the gap we’ve just identified as being where infrastructure, software, information and business architects find their feet.  There’s no reason why people doing these roles cannot have successful and senior careers.  The internet would make us think we all need to become enterprise architects or we’ve failed – not true.  It’s true that enterprise architects routinely have conversations with senior business leaders but when a data centre needs re-locating only an experienced and senior infrastructure architect will get the project completed.

      Let’s looks at version 2 of the figure shown above:



      I’ve used IASA’s definitions here, other groups have slightly different names for slightly different roles.  Either way, you can hopefully see something Google searches won’t easily show you! 

      The question you probably have now is what kind of architect am I?  Well my advice is don’t worry about that for now.  Your “technical solution designer” skills right now are your strongest tools in your armoury for good reasons


      Part Two – Adding more tools to your armoury. 

      Part two of this article will look at how you can start adding additional tools, skills and knowledge to your existing way of working to start demonstrating your value in new ways to new audiences.

      It is available here.


      Get every new post delivered to your Inbox.