On value-governance

What do I mean, when I talk about ‘value-governance’ in an enterprise-architecture sense? In Enterprise Canvas, what does that ‘Value Governance’ cell represent? What do its services actually do, for the service, the organisation and the overall enterprise? This one’s for

Are you an Architect or an Engineer?

If you share any of my professional background and work experiences, I am sure this question must have popped in your head a few times! 

Zachman Framework clearly differentiates between the above two perspectives. As a matter of fact, Zachaman Framework clearly distinguishes between six perspectives, namely; Executive, Business Management, Architect, Engineer, Technician and the Enterprise. But I find the differentiation between Architect and Engineer perspective most interesting, probably because I started my professional life as a Software Engineer and then went onto play a range of Architect roles (Business, System, EA etc.) over the last fifteen years. 

I probably can recollect a dozen instances where these roles overlapped and can also recollect may be another dozen when there was a gap between the two. That probably is more a comment on the Operating Model issues! Referring back to Zachman Framework’s definitions, the two perspectives are defined as below;
Architect and Engineer Perspectives – in Zachman Framework
All Copyrights with Zachman International
The Architecture Perspective is about the Business Logic Designers. People who manage this perspective, namely Architect role profile works closely with Business Managers to understand the key business concepts and then turn them into representations. Zachman actually names them as System Entity and System Relationship representations. The Engineer Perspective is about as Zachman calls it, Business Physics Builders. In other words, Engineers work closely with Architects to turn System representations into Technology Specifications. Zachman actually uses an example of Technology Entity Relationship specifications.


TOGAF though defines Architect roles well; it probably does not clearly differentiate between an Architect and an Engineer at a role profile level. But it does offer a good methodical (as you can expect from TOGAF) and well defined classification of view; namely, Business Architecture View, Data Architecture View, Software Engineering View, System Engineering View and so on. In my opinion that works well too as with these views an organisation can then map roles, responsibilities of Architects and Engineers onto its operating model. 

While many readers of this blog may or may not agree with precise definitions, I think this is still a good enough framework for us to start building operating model constructs around how best do Architects work with Engineers? Or vice versa! In some organisation they may be played by single role profile, in large environments it may be spread across say two or three role profiles. In an outsourced environment, Architect role may still be part of the retained IT staff and Engineers (or Engineering Services) may be procured from suppliers. I suppose, individual organisational operating model will dictate the specifics on these.


What is your experience in your organisation? How do architects work with engineers in your organisation?

References and additional reading: 


Are you an Architect or an Engineer?

If you share any of my professional background and work experiences, I am sure this question must have popped in your head a few times! 

Zachman Framework clearly differentiates between the above two perspectives. As a matter of fact, Zachaman Framework clearly distinguishes between six perspectives, namely; Executive, Business Management, Architect, Engineer, Technician and the Enterprise. But I find the differentiation between Architect and Engineer perspective most interesting, probably because I started my professional life as a Software Engineer and then went onto play a range of Architect roles (Business, System, EA etc.) over the last fifteen years. 

I probably can recollect a dozen instances where these roles overlapped and can also recollect may be another dozen when there was a gap between the two. That probably is more a comment on the Operating Model issues! Referring back to Zachman Framework’s definitions, the two perspectives are defined as below;
Architect and Engineer Perspectives – in Zachman Framework
All Copyrights with Zachman International
The Architecture Perspective is about the Business Logic Designers. People who manage this perspective, namely Architect role profile works closely with Business Managers to understand the key business concepts and then turn them into representations. Zachman actually names them as System Entity and System Relationship representations. The Engineer Perspective is about as Zachman calls it, Business Physics Builders. In other words, Engineers work closely with Architects to turn System representations into Technology Specifications. Zachman actually uses an example of Technology Entity Relationship specifications.


TOGAF though defines Architect roles well; it probably does not clearly differentiate between an Architect and an Engineer at a role profile level. But it does offer a good methodical (as you can expect from TOGAF) and well defined classification of view; namely, Business Architecture View, Data Architecture View, Software Engineering View, System Engineering View and so on. In my opinion that works well too as with these views an organisation can then map roles, responsibilities of Architects and Engineers onto its operating model. 

While many readers of this blog may or may not agree with precise definitions, I think this is still a good enough framework for us to start building operating model constructs around how best do Architects work with Engineers? Or vice versa! In some organisation they may be played by single role profile, in large environments it may be spread across say two or three role profiles. In an outsourced environment, Architect role may still be part of the retained IT staff and Engineers (or Engineering Services) may be procured from suppliers. I suppose, individual organisational operating model will dictate the specifics on these.


What is your experience in your organisation? How do architects work with engineers in your organisation?

References and additional reading: 


Spaghetti Grows in System Architectures – not an April Fools’ Day joke

A replay on breakfast TV this morning of the well known Panarama hoax (1st April 1957) reminded me of the mission we’re on at Bristol to “turn spaghetti into lasagne”. This mission is number 7 on the JISC 10 pointer list for improving organisational efficiency: spaghetti refers to the proliferation of point-to-point (tightly coupled) integrations […]

Spaghetti Grows in System Architectures – not an April Fools’ Day joke

A replay on breakfast TV this morning of the well known Panarama hoax (1st April 1957) reminded me of the mission we’re on at Bristol to “turn spaghetti into lasagne”. This mission is number 7 on the JISC 10 pointer list for improving organisational efficiency: spaghetti refers to the proliferation of point-to-point (tightly coupled) integrations […]

Link: Control Is for Beginners – Deborah Mills-Scofield – Harvard Business Review

“When we don’t give our people the space to take calculated risks, learn, apply, and iterate, we are really risking our future.  While there is a risk to improvising and spontaneity, control brings its own insidious dangers. In our push for perfection, we over-engineer. We add so many bells and whistles that it takes a Ph.D. to use the product. Just because we can doesn’t mean we should.  Just because we can practice to perfection doesn’t mean that’s best.”

Source: HBR Blogs
via Diigo

Hybrid IT or Cloud Initiative – a Perfect Enterprise Architecture Maturation Opportunity

All too often in the growth and maturation of Enterprise
Architecture initiatives, the effort stalls or is delayed due to lack of “applied
traction”. By this, I mean the EA
activities – whether targeted towards compliance, risk mitigation or value
opportunity propositions – may not be attached to measurable, active, visible
projects that could advance and prove the value of EA. EA doesn’t work by itself, in a vacuum,
without collaborative engagement and a means of proving usefulness. A critical
vehicle to this proof is successful orchestration and use of assets and investment
resources to meet a high-profile business objective – i.e. a successful
project.

Hybrid IT or Cloud Initiative – a Perfect Enterprise Architecture Maturation Opportunity

All too often in the growth and maturation of EnterpriseArchitecture initiatives, the effort stalls or is delayed due to lack of “appliedtraction”. By this, I mean the EAactivities – whether targeted towards compliance, risk mitigation or valueopportunity propositions – may not be attached to measurable, active, visibleprojects that could advance and prove the value of EA. EA doesn’t work by itself, in a vacuum,without collaborative engagement and a means of proving usefulness. A criticalvehicle to this proof is successful orchestration and use of assets and investmentresources to meet a high-profile business objective – i.e. a successfulproject.

More and more organizations are now exploring andconsidering some degree of IT outsourcing, buying and using external servicesand solutions to deliver their IT and business requirements – vs. building andoperating in-house, in their own data centers. The rapid growth and success of“Cloud” services makes some decisions easier and some IT projects moresuccessful, while dramatically lowering IT risks and enabling rapid growth.This is particularly true for “Software as a Service” (SaaS) applications,which essentially are complete web applications hosted and delivered over theInternet. Whether SaaS solutions – or any kind of cloud solution – areactually, ultimately the most cost-effective approach truly depends on theorganization’s business and IT investment strategy.

This leads us to Enterprise Architecture, the connectivitybetween business strategy and investment objectives, and the capabilitiespurchased or created to meet them. If anEA framework already exists, the approach to selecting a cloud-based solutionand integrating it with internal IT systems (i.e. a “Hybrid IT” solution) iswell-served by leveraging EA methods. If an EA framework doesn’t exist, or issimply not mature enough to address complex, integrated IT objectives – ahybrid IT/cloud initiative is the perfect project to advance and prove thevalue of EA.

Why is this? For starters, the success of any complex ITintegration project – spanning multiple systems, contracts and organizations,public and private – depends on active collaboration and coordination among theproject stakeholders. For a hybrid IT initiative, inclusive of one or morecloud services providers, the IT services, business workflow and datagovernance challenges alone can be extremely complex, requiring many diverse layersof organizational expertise and authority. Establishing subject matterexpertise, authorities and strategic guidance across all the disciplinesinvolved in a hybrid-IT or hybrid-cloud system requires top-level,comprehensive experience and collaborative leadership. Tools and practicesreflecting industry expertise and EA alignment can also be very helpful – suchas Oracle’s “Cloud Candidate Selection Tool”.

Using tools like this, and facilitating this criticalcollaboration by leading, organizing and coordinating the input and expertiseinto a shared, referenceable, reusable set of authority models and practices –this is where EA shines, and where Enterprise Architects can be most valuable.The “enterprise”, in this case, becomes something greater than the coreorganization – it includes internal systems, public cloud services, 3rd-partyIT platforms and datacenters, distributed users and devices; a whole greaterthan the sum of its parts.

Through facilitated project collaboration, leading toidentification or creation of solid governance models and processes, a durableand useful Enterprise Architecture framework will usually emerge by itself, ifnot actually identified and managed as such. The transition from planningcollaboration to actual coordination, where the program plan, schedule andresources become synchronized and aligned to other investments in theorganization portfolio, is where EA methods and artifacts appear and becomemost useful. The actual scope and use of these artifacts, in the context ofthis project, can then set the stage for the most desirable, helpful andpragmatic form of the now-maturing EA framework and community of practice.

Considering or starting a hybrid-IT orhybrid-cloud initiative? Running into some complex relationship challenges? Thisis the perfect time to take advantage of your new, growing or possibly latent EnterpriseArchitecture practice.

Diversity Versus Replication of Organizational Processes and Information

I recently had the pleasure of joining a discussion among organizational development professionals.  During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geograph…