Lingo Explained : Am I compliant?

Intro
Ever wondered what the difference is between compliant, conformant & consistent? has some nice definitions about it that will guide you in these statements.

Irrelevant

When the targetted specification and the actual implementation do not have anything in common, then this is called “Irrelevant”.

Consistent

Once the specification and implementation share common grounds. Yet not all specifications are met and features that were not covered by the specification are provided, then this is called “Consistent”.

Compliant

Once not all features of the specification are implemented, yet all things that are implemented are according to the specifications, then this is called “Compliant”.

Conformant

If all the features of the specification are implemented according to the specs, yet some features are implemented that are not in accordance to the specification, then this is called “Conformant”.

Fully Conformant

If there is a full match between specifications and implementation, then this is called “Fully Conformant”. You can probably guess how rare this one is… 😉

Non-Conformant

Any of the above situations, yet some features that are implemented are not in accordance to the specification.

Devops : What kind of animal is it, and what dogfood does(n’t) it eat.

Wikipedia
Where I believe from that cornerstone of my hear in this role, I often see it misinterpreted or even abused… So today we’ll talk about the “devops”-animal, and what it should be doing. Let’s first take a glance at Wikipedia (as it’s always a nice reference) ;

DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

So the essence of the role (and yes, it is a role, not an animal, sorry to disappoint you) lies as a bridging function between “Development” & “Operations”. This statement is backed up in the Wikipedia article too ;

DevOps is frequently described as a more collaborative and productive relationship between development teams and operations teams. This improved relationship and collaboration increases efficiency and reduces the production risk associated with frequent changes.

The role of a DevOps professional has similarities to that of a Chief Engineer within the Toyota Production System. Such persons have responsibilities for the project’s success, but no formal authority over different teams involved. This requires technical knowledge in order to convince managers of the needs. Company executives can make convincing the managers more effective by formally endorsing the role of the Chief Engineer.

Many organizations divide Development and System Administration into different departments. While Development departments are usually driven by user needs for frequent delivery of new features, Operations departments focus more on availability, stability of IT services and IT cost efficiency. These two contradicting goals create a “gap” between Development and Operations, which slows down IT’s delivery of business value.

What does it bring?
The article visualizes the role as following ;

Where this might seem a bit different from the “bridging role” as just mentioned, imaging the “Quality Assurance” as the role you often see with your Architect(s). When we go to the stereotypes of each departement; we see that development is typically the team that wants to “inovate”, where operations is the team that wants the least amount of change in order to provide the needed stability. The devops will take both worlds into account. (S)he will introduce things like “High Availability”, “Scalibility”, “Performance”, “Security”, “Data Integrity”, “Monitoring”, and so on from the Operations world. On the other side, (s)he’ll also introduce versioning, automation, release management, and so on from the development world.

So what isn’t it?
Think about the following pitfalls ;

• Devops is not a team…
• Devops does not live within one technology team. (S)he stretches accross boundaries!
• It’s also not the chinese volunteer that will be scr*wed with all your releases.

I think with those statements a lot of companies their interpretation of “Devops” went down the drain…

Still confused?
Still not sure what it is? Check Patrick Debois’s slideshare presentation on Devops, as that one is spot on!

NLP : Avoid “but”

A word to use with caution is the word “but”! Most people are not aware that this word negates everything in front of it… So when you say ;

Good job, but next time…

The result will be that the good part is not remembered. Doing it the way around will then have the opposite effect.

Luckily enough, there are simple ways to avoid this trap. You can use the words “yet”, “however” or “and” as replacements. These words do not have this negative effect, which will result in your message being passee more effectively.

IT Budget : Run, Grow & Transform

One method of coping with your IT budget is by working with the “Run, Grow & Transform – Your business”-model. In essence is sets you to categorize your budget into three areas.

Run covers the general day to day expenses of keeping the IT infrastructure running. Actually, this is your “SIB” (“Stay In Business”). Think in terms of lifecycle management and the human resource costs to maintain your environment.

Grow covers the expenses for expansion of services or growth of the company. Things like extending your virtualization or storage farm probably fall under this category. This budget aims to help the organization introduce new capabilities or improve existing ones.

And Transform covers the costs are made to change your nature. Here you should think of things like implementing a shopfloor system when coming from a paper workflow within an industry. These initiatives might seek to identify, for example, the right technologies for new organizational capabilities; fundamental changes to business processes; or a new product or service offering.

When managing a budget in this manner, you should be able to gather tour full “Run” budget and a part of the “Grow” budget. If you fail to do so, then you have lost the confidence of your board. This part of the budget is in reality the minimal level you need to stay on par. A lower level will force you to start phasing out services from your service catalog!

Organizations that have to trim IT budgets should avoid cutting Run initiatives. Such cuts would introduce operational risk. If an organization already is going through a tough stretch, the last thing it needs is a server, application or network failure. This really is your “Stay in Business” IT budget.

Grow budget items should tie directly to the organization’s strategic initiatives. These initiatives usually are not as mission critical as Run initiatives and often have some time flexibility, which means that they are good candidates for starting early when additional cash is available, or for deferral if cash is tight.

When finances are tight, transform initiatives often are the first to be cut or deferred—unless they are associated with key strategic initiatives that the organization views as essential to its continued operation. Even if the organization doesn’t deem certain Transform initiatives immediately essential, care should be taken when considering cutting or deferring them. That’s because Transform initiatives often are key to the organization’s long-term health. Failure to provide adequate resources to Transform initiatives can stunt an organization’s future success.

Lingo Explained : Greenfield vs Brownfield

Greenfield
A greenfield deployment is an installation and/or configuration where none has existed before. So you start building from scratch

Brownfield
A brownfield deployment, in contrast, is an upgrade or addition to an existing infrastructure and uses some legacy components.

So as an architect, I can say that the number of greenfield implementations in the field are very limited!