Tags

, , , , , , , , , , , , , ,

Back in 2008 Microsoft published An A-Z Guide to ABCBeing an Architect in their Architecture Journals.

Here is my take on an updated A to Z Guide to being an Architect. A couple of these may be similar.

A – Architect

Having the right level of skills as an Architect or engaging an Architect with the right level of skills will depend on the work needing to be undertaken. There are several types of Architect with some specialising in certain areas and others being multi domain skilled. The list below covers some of the different types of Architect- this is not an exhaustive list:

B – Blueprints

Following Blueprints and Patterns either published by vendors (such as the Microsoft Blueprints) or developed internally around your products and services will ensure repeat-ability and cost control around the design process.

Some examples showing different pattern types can be found at Architecture Patterns

C – Contextual Web Era

The up and coming 4th Platform area is the Contextual Web Era

  • 1st Platform – Mainframe Era
  • 2nd Platform – Client Server Era
  • 3rd Platform – Cloud Era
  • 4th Platform – Contextual Web Era

This is an up and coming era with lots of new innovation and developments. Keeping up with developments is key going forward for any architect to understand designs/solutions, art of the possible now and future, innovation and for developing roadmaps for solutions.

D – DevOps

To quote Wikipedia – “DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes”. Having knowledge of DevOps, OpsDev and Agile assist with Architecting a solution for a business understanding their practices and modes of interacting with technology to meet business requirements. A Good book on the subject of DevOps is “The Phoenix Project” by Gene Kim.

E – Enterprise Architecture

EA (Enterprise Architecture) is a blueprint that defines how a business can meet its objectives and strategy. This is achieved by conducting analysis, design, planning, recommendations and implementations through an Enterprise Architecture Framework

Enterprise Architecture Wikibook

F – Four Two Zero One Zero

42010 is the ISO Standard that most frameworks adhere to. Working to a Framework brings structure to your designs and life cycles.

There are a number of frame works available such as:

  • DoDAF
  • MoDAF
  • TOGAF
  • Zachman
  • Other Frameworks are available

Enterprise Architecture Wikipedia Book

G – Governance

Governance is an important part of architecture as it

  • Ensures Conformance
  • Controls Variance
  • Maintains Vitality
  • Enables Communication
  • Sets Direction
  • Issue Resolution
  • Provides Guidance and Prioritisation
  • Promotes Best Practise
  • Minimises Risk
  • Protects IT environments from tactical IT changes, project solutions, and strategic proposals that are not in an organisations global best interest
  • Controlling Technical Diversity, Over-Engineering and Unnecessary Complexity
  • Ensures projects can proceed quickly & efficiently
  • Control over IT spend
  • Quality Standards
  • Efficient and optimal use of resources and increase the effectiveness of IT processes

H – Hands On

It is important to be current and understand the technologies you are architecting. There are lots of options available to get your hands dirty using technology from using Cloud Servers to virtual machines on your compute device. There are other computing devices such as the Raspberry PI that provide a cheap alternative to standing up small farms to learn on.

I – IoT

IoT (Internet of Things) is where physical things are connected by the internet using embedded sensors, software, networks and electronics. This allows the items to be managed, controlled and reported on. My blog posts on IoT Device Security Considerations and Security Layers goes into more detail on this subject.

J – Juxtaposition

Juxtaposition is something an architect should be doing to compare things/items/artefacts etc.
noun;
1. an act or instance of placing close together or side by side, especially for comparison or contrast.
2.the state of being close together or side by side.

Source:http://dictionary.reference.com/browse/juxtaposition

K – Knowledge

I would class Skills with Knowledge. It is important as an Architect to ensure that your skills/knowledge are up to date and where you are unsure of a technology, you have a plan to address and skill up. Build a good CPD (Continuing Professional Development) plan and work towards completing it.

L – Language

With the move to cloud it is important to ensure your scripting skills are up to date as most cloud platforms use scripting to assist with the deployment of environments. This is also true of other DevOps/OpsDev applications. If you are unsure on what to learn this guide may help you – Learn a Programming Language – But which one?

M -Micro Segmentation

Micro Segmentation allows a business to use Networks, Compute and Storage to automate and deliver complex solutions by carving up and using the infrastructure. This segments part of the infrastructures to specific functions/tasks. It can also be used in a security context to segment networks, firewalls, compute and storage to increase security and reduce cyber attacks.  VMware have produced a book “Micro Segmentation for Dummies” that can be downloaded from here.

N – Next Generation

Next Generation refers to the next stage or development to something such as a new release of hardware or software. Next Generation is becoming a common term now to define products and artefacts, an example being Next Generation Firewalls.

O – Open Source

Open Source has been available for a long time with software such a Linux, however there is a bigger shift towards using Open Source and acceptance by businesses. Some examples of Open Source that is now mainstream within business include;

  • Ansible
  • Chef
  • Docker
  • Puppet

P – Performance

Performance can cover people as well as solutions / systems. Performance metrics should be set out at the inception of an engagement then monitored and reported on. This will be a factor in driving Continuous Improvement going forward as well as forecasting / planning for future upgrades and expansion.

Q – Quality

Quality is a huge subject and has a lot if standards governing it and how it affects all aspects of business and architecture. Knowing which standards and how they affect a solution will assist in the whole architecture lifecycle. There are also a number of tools available to help you;

  • Architecture Frameworks
  • ITIL
  • Six Sigma

There is also a level of pride and satisfaction in producing a quality solution and system achieving the objectives and requirements set out by the business.

R- Roadmap

Any architecture/solution should have a roadmap to set out its future. Roadmaps should include items such as:

  • Current state
  • Future state
  • Innovation
  • Upgrades / Releases
  • New Features / Functions
  • End of Life / Replacement

S – SMAC

SMAC stands for Social, Mobile, Analytics, Cloud. SMAC is an acronym that covers the areas and concepts when these four technologies are brought together to drive innovation in business. A good description of SMAC written by a colleague can be found here Acronyms SMAC.

T – Transformation

The majority, if not all systems will undergo a form of transformation. This may be in the form of a simple upgrade or to a complex redesign and migration to something else.

U – UX

UX (User eXperience) affects how people interact with your architecture / design and how they feel about it (emotions and attitudes). With the boom in apps and the nearing Contextual Web Era, UX is one of the most important factors to getting an architecture used. If your users don’t like the system they may find something else to use that they like.

V – Vision

Understanding the vision of your customer and their business is the driving factor for any architecture.

On working with your customer you should look to become a Trusted Advisor and also with your colleagues. A great book on the subject is The Trusted Advisor by David Maister. The book covers 3 main areas which discusses perspectives on trust, the structure of trust building and putting trust to work.

W – WWW

The internet is a key delivery mechanism for systems. Knowing how this works and key components to the internet should be understood such as:

  • IPV4 – IPV6
  • DNS
  • Routing
  • Connectivity
  • Security

X – X86

X86 – is a standard that every knows as its one of the most common platform types available.

Y – Year

Year is for the longevity of the solution you are designing. How many years are your expecting it to last What are the Business Requirements, statutory obligations, depreciation etc that need to be planned in. Consider things like End of Life, Maintenance and Upgrades on hardware and software from a solution point of view.

Z – Zero Defects

The best solution is the one with zero defects, but reaching this goal can be a challenge and can also consume a lot of expense. The best way to ensure Zero Defects is to use:

  • Best Practice
  • Reference Architectures
  • Blueprints/Patterns
  • Checklists
  • Reuse
  • Lessons Learnt

This is my current A to Z and some of the entries may be different in your version so “What is in your A to Z of being an Architect?”

I will look to write some further blog posts on the areas listed in this A to Z