jump to navigation

Why do we need architects anyway? February 10, 2013

Posted by Chris Eaton in architect, architecture, architecture method, artitecture, careers, communications, competitive strategy, EA, Enterprise Architecture, IT Architecture, IT strategy, methodology, methods, people.
Tags: ,
add a comment

I recently spent a very interesting day with IBM and the Corporate Executive Board on the future of architecture. Very interesting, very thought provoking. On the back of this, i have put together this paper Why do we need IT architects anyway?

‘The pervasive nature and continual improvement of technology in daily life presents vast opportunity but it is not always easy to see it. Armed with the right skills, methods and tools the IT architect can help you see the possibilities and exploit them’

Thoughts and comments are welcome. And i am very interested in how you live up to this vision…

Business operational architect February 6, 2012

Posted by Chris Eaton in architecture, Enterprise Architecture, methodology, methods, people, profession.
Tags: , ,
5 comments

funny how time flys…200+ days since i made a post. Hard to believe it!  t’has been a busy time

One idea I have become very interested in recently is the idea of a Business Operations Architect (better names may exist!).

Let me explain this role. I am very interested if this role exists in organisations already and what i might learn from them

My starting hypothesis is:

  • most architects are working on project delivery, architecting new solutions or upgrades to existing ones. Typically they introduce new functionality to end users (business, application or functional architect)
  • some architects design infrastructure (technical or infrastructure architect)
  • some architects are working on Enterprise Architecture; they plan the future IT landscape of applications and infrastructure

No architects are looking at current applications, their functionality, infrastructure, incidints, problems and supporting environment such as monitoring, capacity, performance, etc .

Therefore: a new role is needed: the Business Operations Architects: they ask and answer the following questions:

  • Are users happy with the functionality? what needs to change to improve user experience and function?
  • What incidents have happened, how can they be prevented in future?
  • What problems exist in the current solution and how can we solve them with future releases?
  • Is the supporting operational infrastructure fit for purpose (monitoring, alerting, hardware type/age, software age/support arrangements and if not, what changes are necessary?

They would also play an assist role:

  • are new solutions fit for purpose; functionally and operationally? they would lead or participate in architecture reviews
  • ensure changes are accurately reflected to documentation such as system scope diagrams, interface specifications, architecture diagrams – these often are out of date relating to atrophy of design
  • provide expertise to support incidents and help restore service

is this a good idea, is anyone performing this role, does anyone have a better name for it!

thanks

Chris

who makes architectural decisions and a TOGAF rebellion June 30, 2011

Posted by Chris Eaton in architecture, architecture method, methods.
Tags: , , , ,
4 comments

so i am a fan of the idea of architectural decisions – an architectural decision is the consideration of a problem which needs a soltion (most likely an it solution) and deciding and agreeing what to do

In my opinion, solving problems like this is the very essence of why architects exist because these problems do not often have obvious answers and there are multiple options to solving any particular given problem.

In the last month or so at work I have been looking at who decides which applications are strategic and which are not

I assumed this was a decision the Enterprise Architects made

Much to my suprise in over half of my organisation this decision is not made by people who call themselves architects at all. Instead this decision is owned by IT staff who have come from the business and now are in IT, and by Application Portfolio Managers / Application Managers.

Application Portfolio Management is a role not oft spoken of in the realms of architects but one everyone should be aware of. Application Managers typically own the operational running of a set of applications i.e. incidents, the projects, the cost and customer satisfaction of those applications. This this usually means they talk to the business very frequently about outages, incidents, projects, etc

Therefore adding on an accountability to determine whether an application is strategic or not is a very nature addition to this role. This is probably in consultation with architects but ultimately takes this decision away from the architect, if they every owned it in the first place

I have found this answer rather challenging

I had an assumption that architects would normally own this decision. They are typically technical experts with depth in one or more business domains. The most logical home for this decision

However, on reflection placing the accountability with an APM seems like a more natural home.
– they have a more holistic view of the application, its operational issues, projects in flight, customer satisfaction, cost
– they probably control the project and operational budget and can more easily make a more realistic determination about the ability of the organisation to make an investment or replacement of an existing application
– they do not need deep expertise, they can call on other expertise, most likely architects, to help with the decision but ultimately as the owner of a portfolio are the people who will have to deliver it. This gives a very healthy dose of reality and objectivity

if i put the TOGAF crop circle in front of an application manager, would they have the faintest clue what i was showing them or talking about?

the answer is almost certainly no

if i put the TOGAF crop circle in front of a business person, would they have the faintest clue what i was showing them or talking about?

absolutely not

so a togaf rebellion…

if I changed TOGAF to about analysis of requirements, design options, costs, benefits, value, implementation time, functionality, usability, and risks would they know what i was talking about?

yes they would

and so i am concluding that TOGAF is a method designed for architects by architects using an abstract and inaccessible language useful only to architects

in my opinion a new method is needed which business people can understand. They can understand that there are specific considerations to determining whether one IT solution versus another is better or not

im afraid terminology like Architecture contract, preliminary phase, and migration planning will never be part of a discussion with the business which i ever have

and perhaps thats why application managers are better placed to have accountability for architectural decisions than architects

is anyone interested in creating a method like the one i suggest, i cannot do it alone…

TOGAF 9 Exam Review Worksheets September 8, 2010

Posted by Chris Eaton in architecture, certification, togaf 9.
3 comments

thanks to Khalid Tariq for sending me these excellent TOGAF 9 exam review sheets, i hope you find them useful

download them here -> TOGAF 9 Exam Review Worksheets

IT Architecture as a profession – how the CAEAP is driving forward June 5, 2010

Posted by Chris Eaton in architecture, CAEAP, EA, Enterprise Architecture, profession.
Tags: , , , , , , ,
1 comment so far

Lawyers, doctors, accountants and building architects are a profession – when you employ someone from one of these professions (a professional) you expect a certain level of skill proven by education and examination as well as a high level of accountability that their work will be to a high standard and will keep you on the right side of the law.
Calling yourself a lawyer or doctor, etc. is a protected term in many countries because the public automatically trust people who use these titles.

Personally i am highly in favour of protecting the term Architect, in the IT sense of it, to those who people who truly are Architects proven through qualification – hence i have taken just about every architect qualification i have found

One of the biggest challenges in my mind is:
what is an IT architect?
what do they do and produce?
what education and qualification is needed to prove you are an architect?

the sheer breadth of IT software, hardware, methods, business applicability and pace of change within all of these facets makes an IT qualification look out of date very quickly

However, the Center for Advancement of the Enterprise Architecture Profession (CAEAP) is trying very hard to define what the IT Architecture profession should look like
They are taking ideas like the Doctors hippocratic oath and creating Enterprise Architect version of this.

Today I received a notification of their latest deliverable – the Professional Practice Guide This attempts to define, at a high level, the expectations of someone calling themselves an Enterprise Architect and what the public might expect from an Enterprise Architect. This document is worth a look. It is a useful first step and there is more to do

There is not yet a statement about what an Enterprise Architect is, or is not, there are certainly lots of people using this title and in my experience you cannot be certain about what skills they have

There is not yet a statement about what education and qualification is needed to call oneself an Enterprise Architect and no corresponding course, examination or experiential qualification to prove yourself as an Enterprise Architect. CAEAP could do well to start off looking at the Open Group IT Architecture Certification and building on this

IT or Enterprise Architect is not yet a reserved name, i don’t even know how a job title like that achieves reserved status in law? (anyone know?)

not to belittle the efforts the CAEAP are driving in the right direction and every journey starts with a single step…

Three core skills of an enterprise architect April 27, 2010

Posted by Chris Eaton in architecture, EA, people.
Tags: , , , , ,
1 comment so far

as ever the most stimulating questions come from the populus at large. In response to a question of what skills does an enterprise architect need by Lisa I posted this response

In my mind there are three core dimensions for the skills of an architect:

– Leadership ability
– Technical ability
– Business ability

For leadership – As you become more senior then leadership skills become more important, displacing deep specialist technical skills. Leadership is often defined as the ability to get things done through others which i think is a reasonable take on matters.
Leadership is more about knowing what to do and how to approach problems, achieve buy in and make them happen, than a deep understanding of a subject. Personally in terms of leadership i am very dependant on prior experience on successful projects to guide me as to what to do, and also role models – what would my role model do?

For technical ability – broadly (and matching togaf) you can categorise architects into:
– Application Architecture
– Data Architecture
– Infrastructure Architecture
– Business Architecture
and some might argue integration architecture as it’s own area because middleware is so prevalent and a particularly important area to have good architecture.

Within these domains it is important to have a good level of expertise and have some level of expertise in the others. An application architect with no understanding of data wouldnt be much use.

For Business ability – deep knowledge of a business area or areas and the related business processes is a must for delivering strong business centric solutions

SFIA – Skills descriptions and levels for IT professionals December 4, 2009

Posted by Chris Eaton in architecture, people.
Tags: , ,
2 comments

I was recently introduced to the Skills Framework for the Information Age (SFIA). This framework is geared at IT professionals and the skills and level of skill required in different areas of IT be it in architecture, project management, service management/service delivery, procurement, change management, etc

I like the framework because it keeps things simple by concentrating on a limited set of generic skills and covers pretty much any IT job.

The framework is free and can be downloaded here -> http://www.sfia.org.uk/

I finally took the togaf 9 exam today December 4, 2009

Posted by Chris Eaton in architecture, togaf 9.
82 comments

the exam went ok. The questions were very similar to the Open Group sample multiple choice and scenario questions. I am quietly hopeful i passed. I should find out at the start of next week whether i succeeded

TOGAF 9 July 14, 2009

Posted by Chris Eaton in architecture, architecture method, artitecture, EA, IT Architecture, methodology, methods, people, Uncategorized.
Tags: , , ,
1 comment so far

the last 2 days i have been attending a TOGAF  course run by cap gemini who have made the majority contribution to the latest version of TOGAF

The good

so i learnt that many of my criticisms of TOGAF 8 have been addressed. Specifically it adds:

The Architecture Content Framework which is a library of prior architectures to stimulate reuse and reuse of best practice rather than reinventing the wheel

A meta-model which includes specific artifacts which result from each of the phases i.e. what you should produce and when, this was absent from TOGAF 8

An architecture capability framework which recognised that good architectures result from consistently trained architects with a high level of education and experience. At the end of the day your architectures will only be as good as the people who developed them

TOGAF is now more obviously applicable to solution architecture, when previously i saw it much more in the enterprise/strategic architecture space

The bad

the vapourware of the enterprise continuum remains this is still poorly described and arguably redundant. The continuum was always poor conceived and in-specific now it is super seeded by the Architecture #Content Framework, It is a such a shame the open group cannot shed this kind of legacy and have much stronger editorial process.

The Architecture Development Method still does not split out data and application architecture, this is stil bucketed under Information System Architecture,. Other areas of the open group like the IT Architect Certification recognising that these are separate significant activities. Again it seems the open group is so wedded to the ADM crop circle diagram it cannot, or will not, move forward and improve on prior thinking

The ugly

well nothing was that ugly to be honest, togaf version 9 is is definitely a step forward

how do I become an enterprise architect? May 14, 2009

Posted by Chris Eaton in architecture, artitecture, EA, mentoring, methods, people.
Tags: , , , , , , , , , , ,
28 comments

in a recent discussion with a mentee the question was raised ‘what is the difference between solution and enterprise architect?’

My standard answer to this is to talk about the difference between cityplanners who think about city wide infrastructure and future objectives (enterprise architects) and architects of individual buildings who think about how the house is laid out, how strong roof supports need to be and whether their plan will fit to the city planners constraints.

the next question was, ‘ok how do i become a city planner?’

interestingly the city planner/building architect planner analogy does not answer this question, it simply states a comparison of job roles. So after a little thought here is my answer:

artITecture Skills Model

artITecture Skills Model

Specialists

in essence as a developer (a specialist in IT) you know lots about a specific IT subject matter.  For instance you know how to write J2EE applications, test the code, deploy this into a container, use an integrated development environment and so on. Detailed stuff. In terms of exposure to different types of technology the experience is fairly narrow, working with specific technologies and probably with little care whether the solution is in a Human Resources, Finance, Supply Chain, Procurement and so on.

As a specialist you have some understanding of a particular business area but little thought or care for business strategy.

This growth in business and technical exposure leads to a point where there is a choice: remain specialised or loss the specialism and become more broadly focused – become an architect orchestrating the build but not directly building (rule of thumb says if your write code regularly you are probably not an architect).

Your sphere of influence is your code and immediate team.

Interpersonal skills are not so important as long as the code works!

Architects

Within the architect space the breadth of technical experience grows, but the hands on technical experience is shallow. On occasion deep dives return you to the specialist space.

You have the experience and credibility from the specialist experience to generalise, relate and guide specialists without ever having to have directly worked with the technology.

The trick here is to use specialists for their specialist skills, and bring this together at the solutions level.

In business terms you have probably medium to deep understanding in one or two or perhaps more business areas.

In strategic terms you probably have thought about business strategy within a business area i.e. Finance or Supply Chain, but probably not in a true enterprise sense.

Your sphere of influence is the other architects and technicians on your immediate project. You act as a consultant to key business and project management staff on your assigned project

Interpersonal skills are becoming increasingly important to communicate your ideas and sell them to your immediate project team.

In my own experience moving from a specialist to an architect I clearly decided my time with code was done, and i had a great model who i strong thought ‘i want to be like him and do the job he does’  I still count this role model as one of my best friends

The transition to an architect did stretch me, it was difficult to give up the security of specialisation but it was a decision i never regretted.

Enterprise Architect

you have very broad and shallow exposure to all kinds of technology and business area with depth in some areas. You have a good understanding of technology and technological concepts but the detail isnt of significant interest but the impact it can make is very interesting particularly how it could reduce the cost of doing business or differentiating the business in market.

In strategic terms, and for me this a key differentiator for Enterprise Architects, you have a good understanding of business strategy models (i.e. Porter), think in broad business and IT terms and can apply this knowledge to sell a vision of the future,  the benefits of the future vision and how it can be realistically achieved.

Interpersonal skills become a critical success factor especially negotiation and  influencing. Selling is probably the most important skill. It is required to achieve buy-in for visionary ‘to-be’ solutions at all levels of the business

Your sphere of influence is to aim for company wide impact through process or IT change and influence people who didnt even know they needed influencing!

My own experience of moving from architect to enterprise architect was similar to my transition from specialist to architect, i felt i was giving up a comfort blanket in business and technology architect specialisation for a very broad, perhaps somewhat inspecific role with an emphasis on strategic and inter personal skills, and not too emphasis on technology expertise – something which i had always seens as a personal strength and passion – but again i never regretted the move it was right at the time and i really enjoy the influencing aspects to my EA roles.

In summary, I hope it is clear that business, technology breadth and strategic business thinking is way to become an Enterprise architect, it will take work, it will take opportunity and a good dose of sponsership but in my view it is well worth it.