Thursday, 5 July 2018

Product Mindset in Enterprise IT.

The product mindset is not just about whether you ship commercial software products like Microsoft and Google, it is about treating the results of what you do as a consumer grade product! This is just as relevant to Enterprise IT delivering change to the business as it is to Microsoft delivering commercial product to its fee paying customers. 

Achieving a product mindset in typical Enterprise IT organisations often requires a fundamental change in culture and attitudes that needs to start at the top. 

Enterprise IT needs to start somewhere, so a good first step to achieving this is to consider the use of temporary project specific identities so that team members see themselves more as being part of a product team that has a common purpose and distinct identity and less as individuals working to their own agenda, goals and timeline. 

Using interesting code names (not just acronyms for what the project is doing or delivering) helps to establish an identify for the project, the team, it will increase the sense of purpose and serve as a mechanism for increasing team morale. 

Re-enforcing the team identity by using the code name in documents, presentations, team communications, project plans, e/mail signatures etc are simple ways to create and maintain team identity and spirit. 

Using a code name is especially useful on projects with “virtual teams,” comprising elements from several different groups and/or locations within an organisation.

Once you establish a sense of identity and purpose around a project, it’s an easy next step to recognise that whatever the final deliverable is, it should be considered a product. Principles and techniques that apply to creating products, like those advocated in Agile Methods and Systems Thinking, should still be used, but, the will be more effective in ensuring your project’s successful design, build and delivery. 

Having a product mindset also creates more of a team focus on execution and what is being delivered at the end of the project and less focused on the process individuals need to follow in getting there. That doesn’t mean process is bad or unimportant, just that processes should be used to accomplish the end goal and not just for the sake of it. 

With the adoption of the product mindset, everyone on the team should feel responsible for the delivery of that product, feeling that they have a share in the risk, responsibility and rewards in delivering a product.

Wednesday, 15 February 2017

BCS Article - Eight essential enterprise architecture artifacts

Eight essential enterprise architecture artifacts

February 2017
Floor number 8Svyatoslav Kotusev discusses eight specific enterprise architecture (EA) artifacts that seemingly can be considered as essential for EA practices, and explains how these EA artifacts map to the generalised CSVLOD taxonomy.
Enterprise architecture (EA) practice implies developing and using specific EA documents (artifacts) to facilitate information systems planning. Popular EA books1,2 and frameworks, e.g. TOGAF3 or IAF4, provide exhaustive lists of EA artifacts to be used in EA practices. However, the approaches to EA advocated by these sources represent typical management fads that cannot be successfully implemented in organisations5,6,7,8. Therefore, the comprehensive lists of EA artifacts recommended by these books and frameworks can be considered at best only as ‘dictionaries’ providing little useful information, and, at worst, as a pure science fiction. But what EA artifacts then are used in real successful EA practices? Previously I presented the taxonomy defining six general types of EA artifacts used in real EA practices (namely considerations, standards, visions, landscapes, outlines and designs)9. Here I explain how these EA artifacts map to the generalised CSVLOD taxonomy.

Eight essential EA artifacts

As a result of my analysis of EA artifacts I identified eight specific EA artifacts which can arguably be considered as essential for EA practices since they are found in the majority of organisations with more or less mature EA practices. These eight essential EA artifacts are principles, technology reference models, guidelines, business capability models, roadmaps, landscape diagrams, solution overviews and solution designs. Importantly, these EA artifacts represent eight consistent groups of EA artifacts with very similar meaning found in different organisations regardless of their organisation-specific titles. The titles provided above are merely the most popular titles for these EA artifacts, but the same EA artifacts can be used under different titles in different organisations. Now I will describe each of these essential EA artifacts in detail.
Principles (sometimes also called maxims) describe high-level policy statements having significant impact on both business and IT, for instance, that all provided services should be available to customers via single sign-on. The list of ~10-20 principles is typically defined and then periodically reviewed collaboratively by architects and senior business leaders in order to achieve the agreement on basic rules, values, directions and aims. All business and IT decisions, as well as architectures of all IT projects, are evaluated for their compliance with established principles. Principles are the most ‘classic’ EA artifacts related to the considerations general type (business-focused rules)9. Like all EA artifacts related to considerations, principles represent the overarching context for information systems planning.
Technology reference models (TRMs) (can be called technology standards or split into infrastructure, applications and other more specific reference models) provide standardised sets of available technologies to be used in all IT projects structured according to their domains, often with their lifecycle phases color-coded. TRMs are typically developed by architects and subject-matter experts in specific technologies and then updated in a periodic manner, often yearly. Architectures of all IT projects are reviewed by architects to ensure their alignment to TRMs and thereby achieve overall technological homogeneity and consistency of the IT landscape.
Guidelines (often also called standards) define low-level IT-specific prescriptions or best practices to be followed in all IT projects grouped by their technology domains, for instance, that certain network protocols should be used for particular purposes or certain encryption standards should be used for particular types of data. Guidelines are typically developed and periodically updated by architects and subject-matter experts in specific areas. Architectures, of all IT projects, are reviewed by architects to ensure their adherence to guidelines and thereby achieve technical consistency and, in some cases, regulatory compliance as well.
Even though both TRMs and guidelines describe some implementation-level technical rules relevant to IT projects, they are complementary to each other because TRMs provide lists of technologies to be used, while guidelines define more narrow prescriptions regarding their usage. TRMs and guidelines are the most common EA artifacts related to the standards general type (IT-focused rules)9. Like all EA artifacts related to standards, TRMs and guidelines represent proven reusable means for IT project implementation.
Business capability models (BCMs) (sometimes also called business capability maps) provide structured views (‘maps’) of all organisational business capabilities on a single page, sometimes together with other supporting information like business strategy, objectives, main customers, partners, etc. BCMs are typically developed collaboratively by architects and senior business leaders and then ‘heatmapped’ to identify best investment opportunities, prioritise future IT spending and ensure the alignment between IT investments and desirable business outcomes. BCMs are often considered as ‘entry points’ into IT for business executives.
Roadmaps (which can also be called investment roadmaps, divisional roadmaps, capability roadmaps, technology roadmaps, etc.) provide structured views of planned future IT investments with their tentative timelines aligned to different capabilities or business areas, often outlining their high-level target states after several years. They usually explain how and when ‘heatmapped’ business capabilities will be uplifted. Roadmaps are typically developed collaboratively by architects and senior business leaders and help prioritise proposed IT initiatives, align future IT investments to business plans and initiate IT projects.
Even though both BCMs and roadmaps provide some descriptions of the desired future from the business perspective, they are complementary to each other because BCMs help decide where future IT investments should go, while roadmaps help decide when these IT investments should be made. BCMs and roadmaps are definitely the most common EA artifacts related to the visions general type (business-focused structures)9. Like all EA artifacts related to visions, BCMs and roadmaps represent agreed and shared long-term goals for business and IT.
Landscape diagrams (used under very diverse titles, including system interaction diagrams, relational diagrams, platform architectures, one page diagrams, integration contexts, etc.) describe high-level connections between various applications, databases, platforms, systems and sometimes business processes covering large parts of the corporate IT landscape, typically in their current states. Landscape diagrams are usually maintained by architects and updated at the completion stages of all IT projects modifying the IT landscape. They help architects optimise the IT landscape and select best implementation options for new IT projects. Landscape diagrams are seemingly the most common EA artifacts related to the Landscapes general type (IT-focused structures)9. Like all EA artifacts related to landscapes, landscape diagrams represent reference materials for general technical planning.
Solution overviews (can be called conceptual architectures, solution outlines, conceptual designs, preliminary solution architectures, solution briefs, etc.) describe specific IT projects in a brief business-oriented manner, usually including their high-level architectures, expected business value, estimated costs, risks and timelines. Solution overviews of ~15-30 pages long are typically developed for all proposed IT projects at their early stages collaboratively by their business sponsors and architects. They help senior business stakeholders estimate the overall business impact and value of proposed IT projects and make informed investment decisions regarding these projects. Solution overviews are the most common EA artifacts related to the outlines general type (business-focused changes)9. Like all EA artifacts related to outlines, solution overviews represent benefit, time and price tags for specific IT projects.
Solution designs (can be called high-level designs, solution definitions, detailed designs, full solution architectures, project-start architectures, etc.) describe specific IT projects in a highly technical manner with all the necessary details required to implement these projects. Solution designs of ~25-50 pages long are typically developed for all approved IT projects collaboratively by architects, project teams and business representatives to reflect both business and architectural requirements. They are used by projects teams during the whole duration of IT projects and help implement these projects according to the pre-agreed requirements. Solution designs are the key EA artifacts related to the designs general type (IT-focused changes)9. Like all EA artifacts related to designs, solution designs represent communication interfaces between architects and project teams.
The eight essential EA artifacts described above with their schematic representations mapped to the generalised CSVLOD taxonomy for EA artifacts9 are shown in Figure 1.
Eight essential enterprise architecture artifacts
Figure 1. Eight essential EA artifacts (click for larger image)
Figure 1 shows the schematic representation and mapping of the eight essential EA artifacts actively used in most established EA practices. Importantly, these eight EA artifacts are merely the most typical, but far from the only possible EA artifacts. My analysis shows that reasonably mature EA practices usually use around 10-15 different EA artifacts. Therefore, the full set of EA artifacts used in successful EA practices is not limited to these eight EA artifacts. However, all real EA artifacts can still be mapped in a similar manner to one of the six general types of EA artifacts defined by the CSVLOD taxonomy9.
Bernard, S.A. 2012. An Introduction to Enterprise Architecture, (3rd ed.). Bloomington, IN: AuthorHouse.
Spewak, S.H., and Hill, S.C. 1992. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology. New York, NY: Wiley.
TOGAF. 2011. 'TOGAF Version 9.1,' G116, The Open Group.
van’t Wout, J., Waage, M., Hartman, H., Stahlecker, M., and Hofman, A. 2010. The Integrated Architecture Framework Explained: Why, What, How. Berlin: Springer.
Kotusev, S. 2016. 'Enterprise Architecture Is Not TOGAF' Retrieved 21 January, 2016
Kotusev, S. 2016. 'One Minute Enterprise Architecture' Retrieved 30 June, 2016
Kotusev, S. 2016. 'The Critical Scrutiny of TOGAF' Retrieved 15 April, 2016
Kotusev, S. 2016. 'Enterprise Architecture Frameworks: The Fad of the Century' Retrieved 3 August, 2016
Kotusev, S. 2016. 'Six Types of Enterprise Architecture Artifacts' Retrieved 26 November, 2016
Image: iStock/157423692