Reflection: Remember this is Business and IT!

I fear I've subliminally focused on IT centric thoughts these last few posts... Which is quite wrong!  Everything I've said applies as equally to Business Architecture as it does IT Architecture:

• "Standard Actors" may be IT, but they have to be grounded in Business Architecture's "Standard Roles", whether they be roles in the business or roles in IT.
   
• A reference IT design might be to do with data distribution; but there is equal need for reference Business Process Models or Entity Relationship Diagrams. And only when the BA's data models and process models are understood, particularly their non-functional characteristics, can IT focused design decisions be made on data placement in the first place!

I know there are some who, while enthusiastically advocating the need for both, describe it as "Enterprise Architecture supporting Business Architecture", implying EA is wholly focused on IT. While there may be a historic truth in that - that EA was a wholly IT centric thing - you have to go back quite a few years to find that narrower view.  Today, EA "is" an integrated blend of IT and Business concerns and considerations.

Making it work ("People"): Teams

"You is not singular - it's plural!"

It's probably pretty obvious by now that Architecture and Design are not things to be tackled on your own, whether it be a need for such a broad range of skills and knowledge, or the value brought by checks and balances of design reviews and architecture conformance -there is such a spread of capabilities in the roles of Architects and Designers that, even if it were sensible to do a design or architecture alone the probability of falling into a hole is horribly high.

But there is a dimension to  "teams" that is very close to my heart...

Mentoring
and the transfer of experience and capabilities from the industries "elders" to their junior colleagues in the work place (as much as the classroom).  Trouble is, it just doesn't happen.

Why?

Because today the pressures to "just do it" are so great, budgets are so tight, and the rate of change scary; that people don't have time to coach and guide - in fact the best of us struggle to just keep up with new "fashions" and marketing messages(*), we seem to spend all our time working out how to exploit the next great idea.

As a consequence, as each generation succeeds the previous one, all we seem to do is constantly repeat the errors of history ... for example, the expertise captured in IBM's early infrastructure design method (distilling the early experiences of distributed systems design in 1993) is still (sadly!) state of the art, and yet is so often ignored (maybe it's simply not known) by today's designers.

Why?

(And this is controversial) because we seem to be the only industry where architects and designers report to the project manager.  In all other industries the project manager ensures the delivery of the design created by the design team.  In our case, it's more "have you (the designer) finished yet?"!  If only authority... and I mean authority in the Design Authority was more widely recognised as the heart of a good solution program!


(*) I refer to our industry as a "fashion" industry, where marketing "fresh new ideas" on how to "do IT" seems to be a constant compelling force.  But how new is new?  How different is the underlying technology of IT?  It's always been about exploiting processors (execution), memory and disks (information) and I/O (communication).  Even "new" design styles such as cloud are not that different from the bureau services I remember from the 1980s...  We should be able to work it out, building from "fashion" to "fashion", rather than it all starting over he moment a new buzz word emerges.

The trouble is, we can't, we're not "allowed" to, there's no time...  And this is the root cause of our failure to successfully pass on our skills to the next generation - put simply the real fashion industry as a whole "knows how to sew a seam".  In other words, the clothing industry as a whole understands the basics of dress making; there is no differentiation between enterprises at that level.  We, though, do not have an industry wide understanding of how to successfully design IT systems - why else are there so many news headlines of yet another failure?

Making it work ("People"): Context (Architecture)

The "Who does it when?" of Architecture
Whether it be "upstream" transition planning, or "downstream" ABBs and reference designs, the "when?" of  who does Architecture is rather different than that of Solution Design - fundamentally because Architecture is ongoing "for ever", whereas SD programs and projects have beginnings, middles and ends, often in the stages I described earlier.

So for Architecture "when?" is always "then, now, and later"!   

I'll discuss the direct implications on the lifecycle and useage of the architecture itself when I get to "Process", so for the moment I'll restrict muself to saying Architecture always needs a cyclical refresh, whether annualy or more frequently.

But whatever the reason, rate and nature of change, who changes it?
Architects of course, whenever and whyever the "when"!  

• "Downstream" Architecture guidance and governance
  Whoa, just a minute...!!!  My next topic includes "Persuasion"... and a particularly powerful form of persuation is involvement - for example, in previous posts for downstream Architecture I've discussed the Architects' "curatorship" of "their EA" and how, by engaging the design community directly in the creation of the Architecture, can be a powerful means of gaining commitment from them; whether that engagement be their specification of the ABBs (such as "standard actors") they want to use, or the creation of a specialised reference design based on those ABBs.  Once created, it is almost a given that they will then be happy for the Architects to curate "their" architecture.
  
  Doing it the other way, at least in in my culture, the challenges of "me" getting "you" to use "my" architecture are, well, challenging.

 

• "Upstream"EA ("Transition Planning")
  Here, things are different, where the broader, less "precise" skills of the architect comes to the fore - unless of course the topic is somehow specialised, when the aid of a more technically competent designer is vital.
  
  And of course the stakeholders are different, with skills not necessarily tuned to the challenges of Transition Planning - if the Architect's don't do it, with a hoistic view of the needs of the whole enterprise, then the alternative is almost always to leave it to those with vested interests in specific systems that "they" want to see enhanced or implemented.

 The organisational "who does it where?" of Architecture
Architecture is universally more successful when the people involved are "in house".  Can you imagine the implications of outsourcing it?  Giving an external agency authority over your EA?

Which is exactly what a client of mine once did, outsourcing the whole of their "design and architecture" practice to IBM!  Only when they realised... sorry, only when they experienced the implications did they pursuade IBM to sub-contract back in-house their own previous employees as the overarching architecture function.

The geographic "who does it where?" of Architecture
"In house, on shore".  End of story.  Well, not quite - clearly, some of the " filling in" of detail, such as ABB specifications might be more cheaply managed off-shore... But I'm not convinced.  The "who" doing Architecture have to be in-house, on shore, physically as close to their stakeholders as they can be.

Reflection: is this really how it is?

By now, many of you will be thinking, maybe even saying "yeh, right, in your/my dreams!"  and "Ian's describing a utopia, that cannot exist in this real world!"

Well, funnily enough, it's a rare sight in my world, too.

But that's because my experiences have largely been with dis-functional "Architecture and Design" departments, looking for guidance and help to "make it work"- and all of my "Making it Work" posts are based on practical, first hand experience with these clients, that I have seen work, that have transformed (or at least improved) the effectiveness of the team (or teams).

For example, the "three body" Architecture Governance structure is missing - usually one of the three bodies is not present.

• whether it be the Architecture Board (AB), meaning that the Office of the Chief Architect (OCA) has no "teeth"
• or the OCA is not there, which means the AB has a confused and frustrating relationship with the Program's Design Authority (DA) - basically they do not speak the same language, nor have the same set of issues; 
• or there's no DA, which means the AB and OCA have no-one "in authority" within the program to work with.

All those capable and competent "Architecture and Design" departments have not needed my (or my IBM colleagues) help, so I've seen them rarely.  But they DO exist - there's plenty of evidence in the literature, conferences  and on-line reviews to prove the point.

Making it work ("People"): Context (Solution Design II)

Wow, that was a   l o n g   posting!  Sorry!

My previous post focused on the "when?" of  Solution Design - this one relates to the "where?".  But I do not only mean "in the office", or "Country X" - that sense of "geographic where" is important, but so is the "organizational where":

Organizational Where (Solution Design)
Which organization, or department, or business unit "does" the solution design?  In fact, why should we care?  Put bluntly, "vested interest"!

The forces at play on an enterprise's "internal team" of solution designers are quite, quite different than those of an external agency, be they engaged in a purely "early design" stage, or fully engaged as a Systems' Integrator or Package Implementer.  For example, whose reference designs will the solution be based on?  Those known to the designer, obviously!

• Which means an internal solution design team are more likely to know, understand - even have contributed to the Enterprise's architecture, and therefore far more comfortable with using it as a guide for their solution, and therefore more likely to lead to "architecture conformance"  in balance with the cost/benefit concerns of the wider team, across the full lifecycle of the system (deployment through change to decommissioning)

• On the other hand, an external agency is far less likely to be familiar with the EA - and in fact may face pressures to create a design more in keeping with their own agency's reference materials - the forces at play here being the cost/profit of the engagement. And if the scope of the engagement is no further than deployment, then designing for the full lifecycle is likely to be low on their agenda...

• And then there's the Enterprise's Architects - the forces at play on them are different again - less of a formal "design mindset" and more "big picture stuff", trhey will have a strong desire to follow their own architecture, and "negotiate" the requirements to fit ! :-)

So what can we do to manage these forces so we create the "right" Solution Design?  Invoke the power of Politics!!!!  And specifically that part of politics that ensures the three Architecture Governance bodies are in place, to oversee the design's creation (the program's/project's Design Authority using the EA), its fit to the wider enterprise (the enterprise's "Office of the Chief Architect" in concert with the DA), and conflict resolution (! - the "Architecture Board" in concert with the other two).

Geographic Where (Solution Design)
Where in the world's the best place for Solution Design?

• Instinctively - I say, without hesitation, "locally". Local to the rest of the project team, local to those responsible for specifying requirements, local to those expected to do the detailed design and subsequent deployment.
  
  Why?  Why in this world of outsourcing and off-shoring?  Because Solution Design is hard.  It's iterative, ambiguous (in it's early stages) and it's complex.  It needs face-to-face (and face-to-whiteboard) working ideas and options need to be expressed "tangibly" in "real time", sometimes with passion...
  
  Once, maybe 10 years ago, I was facilitating a design session, attended by expert end users and sponsors as well as my client's designers.  We were "pre-proposal", so things were a bit "foggy", and we were resolving conflicting requirements using the HUGE whiteboard in the Boardroom and Post-Its(r) to represent our model's elements.  As I and my fellow designer's looked on, the two sponsors fort over where a Post-It should go - in the end neither would give in, and the Post-It tore in two. Now THAT'S what I call "local engagement"!

• But it's often inevitable that some (or all) of the Solution Design is performed "remotely", in which case I implore you to ensure some level of "on-shoring" representation is locally available, to act as the human gateway between the real people in the enterprise, and the real people "somewhere else". 
  
  The (small) local team is then responsible for understanding and negotiating the requirements with those outside the design team, and transforming them into formal descriptions for their off-shore colleagues - as well as handling Architecture Reviews - which implies the one-shore team must include some aspect of the Design Authority.
  

Making it work ("People"): Context (Solution Design, part I)

It's all well and good knowing "what" to do, and "how" to do it, and I've discussed at length the need for us to understand "why".  The previous posts on "Politics" and "Role" pretty much addressed "who", but what about the other two "W"s immortalized in Kipling's "Just So" stories - "when" and "where"?

Let's discuss these first in terms of Solution Design ("when" and "where"), and then in a subsequent entry Architecture:

"When" Solution Design
Design (and Architecture), just like Mark 14:7, should always be with us; from before the first inkling of the need for an IT based solution to a business challenge, to change requests and alterations made to a system many years after its implementation.

But it is vital to recognise the degree of effort - by which I mean the time and money put into the detail, accuracy and completeness of a design will vary enormously from one end of that cyclical timeline to the other:

• In the beginning, probably well before formal funding is available, all that may be needed to verify the viability of something new are sketches and outline, natural language based descriptions of requirements and their corresponding solution(s).
  
  As such, the people most likely to focus on a solution's design at this early stage are the enterprise's architects in the role of designers, instinctively using "their" EA.

 

• Obtaining funding will probably require a more complete design, albeit one that cannot be as detailed or as accurate as will eventually be needed for development - but it must be good enough not only to convince the "upstream" stakeholders of the design's viability and (probably) the manner of it's development /deployment whether via phases, or (sub-)projects, or some other means of chunking a large complex programme.  
  
  Who's most able to fulfill this role?  IMHO, this depends strongly on the final W, "where":  it may be the case that this stage is done "in house", by the enterprise's architects " completing their EA/ABB inspired sketches; but deciding to use an outside agency, maybe with a view to them taking on the subsequent program/project, means it's more likely to be designers, with a more complex relationshop to the enterprise's EA.  Either way, this forms the basis of...

 

• Outline programmetheoject Solution Design is likely to be the heart of any programme's or project's first phase, and as such, it will probably need to keep the "completeness" theme going with the intention of identifying (or confirming) a number of highly cohesive, loosely coupled projects/sub-projects that can "safely proceed" under the design guidance provided by this complete /outline design, while being confident of their pseudo-independence from fellow projects/sub projects.
  
  Almost always, the people for this stage are battle-hardened solution designers - intent on putting (rarely maintaining) their mark on the program.  And my "rarely" indicates an anti- pattern: change the team between proposal and delivery!  So much better to keep the forces of change to the direct solution requirements, and not meddle with the design based on a new broom's wxperiencw.  But, as I have posted before, there's also a strong case for the direct involvement of EAers, and not only if they were the authors of the previous stage

• More detailed project/sub-project Design, focusing in on the (sub-)project's narrower scope, and as a consequence going to a lower level of detail, and a far greater confidence in the design's accuracy and suitability to the (now detailed!) requirements.
  
  Undoubtedly, the person whose bailiwick this is, is the solution designer, ably supported by the architect's reference designs and "wonderfully detailed" ABBs and their preferred implementations!

As a side thought, not directly related to "people" but none-the-less vitaly important is how "deep/detailed/complete" must the design be for each of these contexts?  I have no idea.  Well, of course I do in any given situation - what I cannot do is give you firm/confident indicators - except:

• Early on, things are probably more easily described in "free format" sketches rather than formal views - hence an office automation tool is probably more attractive than a proper CAD tool.  But history tells us this is a dreadful anti-pattern, because "once in PPT/Open Office, always in PPT/Open Office". 
  
  But it is also the case that "things" are far more readily defined than "relationships between things" - as proved by our ability to identify ABBs as candidate building blocks before any structure is formed,and to construct lists of preferred software.  Critically, CAD tools are generally really good at maintaining "thing integrity" while allowing "free format" relationships between things, on sketches such as "Architecture Overview" and "Current IT" diagrams - in other words, use CAD tools from the Get Go!

• Towards the end, there is a limit beyond which we do not go:  the insides of our model's elements.  A node or component is - must be respected as - a black box - it'a atomic.  We do not look inside, nor do any internal design work - that is the bailiwick of the detailed design professional. probably far more versed in technology limitations and exploitations that fits them better to this work - in other words, use CAD tools that focus on "something of everything" (limited depth but full scope/breadth), not specialist tools that do "everything of something" (deep depth on a narrow scope, be that "requirements", or "s/w design")!

OK - those of you who've followed me from (near) the beginning will know that's not true - we DO look inside nodes and components (and other model elements), because we list the key things in the insides - methods and data items "inside"(*) a component, or DUs "inside" a node.  What we do not do is describe how a method is accessed via an interface to manipulate data items, responding via a (different?) interface back to the requester.

(*) it's a little inaccurate to describe DUs as being "inside" a node or Methods "inside" a component - rather, a component or node "is" the aggregation of its parts, rather than being something greater than the sum if its parts.

"Where" Solution Design
The subject of my next post!

Reflection: roles and careers

Clearly how "good" one is in a job using the capabilities defined in the job's role(s) determines one's professional and therefore career position, but - and this is key - it can also determine one's profession.

Sometimes, the career profile of a role/job shows a steady, balanced progression, across many capabilities both hard (technical) and soft (people) and it is therefore quite reasonable to enter that profession "early" and look forward to a smooth(!) journey up the ranks.

I think Project Management has this profile - while senior project execs clearly need superbly honed interpersonal skills, they are "more of the same" being demonstrated daily by their team.  And their technical(*) skills show similar profiles.

(*) remember "technical" is not the same as "technological": the ability to create and use a Gantt chart is just as technical as creating and using a component structure view.

Is architecture the same?  I'm not sure... I don't think so.  Why?  Because of one factor: knowledge.  By which I mean the underlying knowledge of the industry (business architecture) and/or application (IS) and infrastructure technologies (IT) upon which an architect applies their technical and people skills.

Sometimes this knowledge has to be bang up to date, but (and this may be debatable!), may be more focused on " first principles", learnt many years ago when technologies were quite different - or so many think!

Either way, there feels like there needs to be a pre-req role to that of the architect - as a technical specialist, such as "Business Analyst" or "Detailed Designer" roles which have a high " knowledge index", enabling the practitioner to cut their teeth on the detail, before switching to a role that takes them away from this "everything of something" world to the world of architecture's "something of everything".

All of which begs three further points:

1. It is likely IT and Business Architects enter the profession later than their peers in other professions such as Project Management and Consulting, probably simultaneoulsy switching from another more technology focused job.
2. There is no fundamental reason why a technical specialist would want to switch to architecture - in fact it's probably the case that many (if not most?) people in technology-centric roles/jobs remain in them for their full careers - why not?
3. It is perfectly possible to enter the architect profession early, so long as provision is made for "knowledge", maybe via assignments into other roles: the key is not to confuse an architectural "technically content rich" role with the softer-skilled consulting profession!

Making it work ("People"): what's in a role?

Role is different from job.

• The notion of "role" is to organize sets of skills and abilities into coherent and valuable descriptions of an individual's capability.
• A "job" describes what that individual is expected to do - sometimes disconnected from the role they are capable of satisfying!
• A "job title" is an attempt to characterize the combination of "jobs" one person can do, at a certain level of maturity or seniority.

Joking apart (was I joking?), clearly the role has to be capable of doing the job, and indeed may define what's needed for many different jobs - whether these job's form part of a job title. And of course a job may require the incumbent to fulfill several different roles.

Confuse the three, and you have a nightmare.  Particularly if your professional qualification is unfortunately "job title based"!

For example, while at the moment I am generally lumping "Architect" and Designer" together (hitherto fore, without distinguishing these as labels for role, job or job title!  In this entry, I mean...), the role of architect demands different skills to that of designer - something I highlighted in an earlier posting where I discussed how an architect may be more comfortable with the job of "lead designer" early in a project than a designer (oh boy - similar names for role and job!!), given the job's higher levels of ambiguity and uncertainty.

These distinctions of roles within our "profession" is critical if we are to succeed - each role may be honed to fit a particular standard job, but each and every one is built on a single core set of "hard" and "soft" skills that every architect and designer must have.  Here is not the place to go into detail, but a few key capabilities in that core can be listed as "the ability to..."

• Speak several languages, from Consultant to Cobol
• Predict the winner of next years Superbowl/FA Cup final
• Know when "yes of course!" means "I've no idea!"
• Keep your head when everyone else has lost theirs.

Clearly intended to be a light hearted list, but undoubtedly with grains of truth for the roles' soft skills.  the core role's "hard skills" fall into two categories, both of which are needed by all roles: those associated with Architecture, and those of Design - yes, a designer needs to understand and be able to contribute to architecture work, and ditto an architect and design.

Additional capabilities are then needed depending on specialism - on a general level, an enterprise architect speaks the same language as a solution designer, but uses it is very different ways.  More specifically, a designer (or architect) may specialize (performance, security, systems management, data), or remain more generally focused on a level (business, application, infrastructure).

These mixes of capabilities define the skills needed in the jobs of a Chief Architect through to those of a junior data modeller - which prompts another thought: roles and careers...

People - who's that then?

You!

And you're brilliant.

In my opinion, you have to be, to be a good architect(*) - I believe the role of architect, be that specialised to IT, Business, Solution, Performance, Enterprise or whatever, is one of the hardest roles - if not the hardest in the industry.

(*) remember I am using "Architect to cover both "Architect" and "Solution Designer".

Of course I would say that wouldn't I... but think about it:

How different could our two sets of stakeholders be?!  Commercially driven Business execs to the left; deeply technical, technologically savvy detailed design specialists to the right - each expecting us to speak "their language" as we understand and help them solve their widely differing challenges - while we try to be effective and efficient between ourselves in our various roles endeavouring to communicate our architectures and designs clearly and unambiguously. 

How complex is our subject?  Could it be any more complex?!

• You need the technical skills to explain (formally or informally) some of the most challenging types of architecture and design I know: the challenge of IT systems is that so much is virtual and intangible - can you see software?  And we can only imagine data flows - the airflow through an aero-engine's compressor, combustion chamber and turbine is far more tangible.. seen and heard!
   
• How many dimensions do we need to get our heads around?  As far as I can tell, this blog is over 19,000 words long - and I'm not finished yet; and I'm only scratching the surface of...

• Enterprise and solution/system level thinking, for both architecture and design,
• The Architecture/Design of Business as much as IT (and their complex interlock),
• The cube's multiple thinking model viewpoints,
• The non-functional ("goodness") needs of a system, as well as its functional behaviour ("stuff done", whether done well or not).
   
• And to cap it all, the highest levels of inter-personal soft skills, which I suspect can often be more challenging for us - certainly on many occassions more important than our technical expertise!

In other words, you are amazing!  Which is why the qualifications available today as an IS architect are so "Professional", and why architects tend to be older... sorry, more experienced than some other roles within our industry.

But one critical thing is still missing - "you" is not singular - it's plural!!
 

Which means I have  three "People" topics to discuss...

• The role(s) of Architects
•  The context(s) of our work
• Working in Teams
  

Yes there are!

Or should that be "yes there is!"?

Either way, I am delighted to have had a good (private email) response to my question, matching the tone and enthusiasm of my two " public" commentators.  And a potential expansion of my reader base via a few offers of publicity is an added bonus!

So on with "People"...