Understanding Architecture Architecture Principles: Part 3

Understanding Architecture Architecture Principles: Part 3

In Part 1 we looked at the symptoms experienced by an organisation that does not have Architecture Principles in place. We stated the official TOGAF definition and then discussed the concept of Architecture Principles, exploring the psychological reasons behind their usefulness.

In Part 2, we looked more deeply into the properties of a Principle; we understood the formal structure in which they should be written, and the consideration that must be given to their interaction.

In this third and final part of this series on Architecture Principles, we will explore the use of Principles in the governance of an organisation, and I will provide and expand upon a set of Principles which I have designed specifically to support the adoption and governance of platform-based operations within an enterprise.


Blank Pages are Scary

Many of our customers are either new to the Now Platform, or they are expanding their use of it. Operating a software platform of any kind requires a different mindset to handling an IT landscape of standalone or networked applications. Data flow is the key to getting the most value; when data can be shared seamlessly across an enterprise-scale platform, reused by different packages and applications, and collated and reported easily, its power multiplies. The platform goes from being a series of useful point solutions to a single, powerful engine that can drive a business forward. Getting to this point, however, requires that key decisions are made in a way that is consistent with both the needs of the organisation and the platform; the organisation needs to create a set of Principles that it can uphold through Governance.

As any author knows, a blank page can be intimidating. For many people, just the thought of composing normal prose is enough of a challenge to invoke writer’s block, but the problem is compounded when one is faced with creating something that must have formal structure. It’s easier to write a postcard than a sonnet.

Creating Architecture Principles from scratch can be a challenge; it requires knowledge of business, technology, and architecture standards. The Principles have to be pitched at the right level: not so high that they become vague statements of intent (‘We will be the best at everything’), and not so detailed that they are irrelevant in most cases (‘We will use the AcmeFinance App when the customer returns a faulty product on Thursdays.’)

When you are working on tight timescale, and you’re faced with the task of creating Principles, there are two very good reasons to have a draft set as a starting point:

1.????It is easier to edit than to create

2.????People can more easily replicate “good” when they know what it looks like

With this in mind, I have created a set of Principles for the use of those engaging on major digital transformation with ServiceNow.



The Set of Principles


Theme: Culture

P1: Drive Compliance

  • Explanation: The systems we use must help us to maintain legal, regulatory and safety compliance.
  • Rationale: We have to maintain compliance, and the systems we have should make this easier to achieve.
  • Recommended for: Organisations in highly regulated industries, such as oil and gas, and banking.


P2: Great Place to Work

  • Explanation: Changes will be made with a view to improving the day-to-day experience of staff and customers.
  • Rationale: A happy workforce is healthier, more motivated and more efficient, and a happy customer is more likely to return and recommend us to others.
  • Recommended for: Customer/User centric organisations, those who want to reduce staff turnover, and those who have or hope to attain a particular reputation for service quality


Theme: Experience

P3: Consumer-Grade Experience

  • Explanation: The applications that we use at work should provide a similar, high-quality user experience to the consumer-grade applications we use at home.
  • Rationale: Systems that provide intuitive, high-quality user interfaces and performance are more enjoyable to use and promote work efficiency.
  • Recommended for: Organisations wanting to improve performance and efficiency, particularly for those with a lot of staff working from home. (Works well with Principle P2.)


P4: Consistent Experience

  • Explanation: We will minimise training time and increase productivity by having familiar user interfaces.
  • Rationale: It is easier to use systems that are intuitive, familiar, and well organised.
  • Recommended for: Organisations using multiple ServiceNow products, or wishing to develop apps on the platform; also, those in which staff often transfer between locations and departments.

?

P5: Comprehensive Service Catalogue

  • Explanation: The services we offer will be made visible and accessible to the intended users.
  • Rationale: People can only use services that they know about and to which they have access.
  • Recommended for: Organisations seeking to use Employee Portal, encourage self-service, reduce the volume of support calls, and improve staff productivity.

?

P6: Multi-Channel Delivery

  • Explanation: We will prefer solutions that can deliver a service through many channels, such as voice, web chat, mobile, self-service.
  • Rationale: We have a diverse workforce, and a broad customer base, with people with different physical needs and a variety of ways of working. We want to accommodate their needs and provide appropriate ways for them to access services.
  • Recommended for: Everyone, particularly organisations with a workforce/customer base that is largely mobile and/or remote.

?

P7: Efficient Communications

  • Explanation: Our workflows should be designed to reduce the need for emails.
  • Rationale: Excessive email and rework takes time and adds little value.
  • Recommended for: Those wishing to optimise and automate processes, and review the ways in which communications and notifications are sent.


Theme: Performance

P8: Useful Data

  • Explanation: Data quality, accuracy, and completeness is essential if our systems are to be useful.
  • Rationale: Bad data gives bad results. We want our systems to support and enable good data management
  • Recommended for: Organisations seeking to use the CSDM/CMDB, and to improve their data management and mastery

?

P9: Connected Data

  • Explanation: Employee services will be decoupled from functional siloes; bringing together disparate sources to improve data governance and quality.
  • Rationale: Siloed data leads to high maintenance, inaccuracy, and duplication. We want data to be cross functional and connected. Employee services need to be decoupled from functional siloes.
  • Recommended for: Organisations wanting to use the CMDB to improve data quality and to share data across multiple products on the platform.

?

P10: Connected Systems

  • Explanation: We will prefer solutions that enable our systems to be closely integrated.
  • Rationale: Connected systems are better able to share data and are easier to discover and monitor.
  • Recommended for: Organisations seeking to rationalise their applications, reduce the cost and maintenance overheads of their application landscape, and to bring as much of their operations as possible onto the platform.

?

P11: Process Automation

  • Explanation: Wherever possible, we will engineer our processes so that they can be automated and will prefer systems that will enable automation.
  • Rationale: Process automation can reduce the amount of human effort required to deliver a service, so that more can be done for the same investment of human resource.????????????????
  • Recommended for: Those wishing to improve customer service, productivity and efficiency, and to reduce manual and repetitive work. (This pairs well with Value Stream Analysis, and with Principle P11.)

?

P12: Differentiated Capabilities

  • Explanation: The capabilities between business lines (especially similar ones such as Tax, Audit, Consulting, etc) will be clearly delineated and clearly aligned to organisational leadership.
  • Rationale: By having clear roles and responsibilities, we can ensure that the different capabilities to not duplicate each other's work unnecessarily.
  • Recommended for: Organisations who have, in the past, suffered from the effects of overlapping capabilities, such as duplication of effort, poor reporting lines, and conflicting process flows. Also, those wishing to restructure geographically, and possibly to divest or outsource capabilities.


P13: Information Flow

  • Explanation: Processes will be designed to enable data to flow seamlessly from end to end.
  • Rationale: Data powers our business, and enabling it to flow easily and securely through our processes will save time, effort and money.
  • Recommended for: Organisations who are developing their use of the CMDB so that they can improve their data quality, and share data between different parts of the Now Platform.


P14: Process Transparency

  • Explanation: Processes will be mapped and published for colleagues to see and share
  • Rationale: Our processes need to be easy to understand so that we can have trust and confidence in them.
  • Recommended for: Organisations building their Enterprise Architecture Capability, and using it to empower their staff. Making architecture comprehensible and visible, and encouraging people to comment on it, empowers the staff, and helps to drive continuous improvement.

?

P15: ?Anytime, Anywhere

  • Explanation: We will preferentially select systems that will provide access to services to colleagues anytime they need them, and anywhere they are.
  • Rationale: Our workforce is distributed, and many travel to customer sites in different regions and time zones.
  • Recommended for: All organisations with a significant remote workforce, or one in which staff frequently travel. This Principle has become particularly important in the wake of the Covid pandemic, which has resulted in a significant increase in home working.

P16: Pro-active Engagement

  • Explanation: User Interfaces and Services will be designed to encourage the pro-active engagement of colleagues and customers.
  • Rationale: People are empowered when they are able to address their needs quickly and easily. Self-service for simpler issues also frees up support staff to handle the more complex problems that may arise.
  • Recommended for: Organisations wanting to improve efficiency and staff satisfaction scores, and to reduce the load on call-centre support staff.

?

P17: Continuous Improvement

  • Explanation: Metrics will be gathered and analysed, and acted upon to enable continuous improvement of process and service delivery.
  • Rationale: With metrics we will be able to measure the impact of change and the quality of service delivery. Having this feedback will enable us to make informed decisions and continuous improvements.
  • Recommended for: All organisations. This Principle acts as a reminder to include metrics across the board, and to use their output to improve performance and to give praise when it is due.

P18: Drive Productivity

  • Explanation: We will seek to reduce process steps, enable self-service, and ease common tasks, to increase productivity to increase without increasing the human effort required.
  • Rationale: No one enjoys processes that take too long, and they take up time and energy that could be better spent elsewhere.
  • Recommended for: All organisations focussing on process improvement, and/or delivering Service Oriented Architecture. (Works well with Principles P11, P13 and P17)


Theme: Program Approach

P19: Use before Buy

  • Explanation: When applications are fit for purpose, we will make good use of them in preference to buying additional applications.
  • Rationale: We should make the most of our investments, and explore ways to use their full functionality, rather than buying additional software that makes our systems more difficult and expensive to manage and maintain.
  • Recommended for: Organisations that in the past have tended to proliferate applications, buying more without considering if they already had something that could do the job. (This is a good example of a Principle that may need to be temporarily suspended in order for major transformation to take place.)

?

P20: Adopt not Adapt

  • Explanation: As far as possible, we will use applications out of the box, and avoid making customised or bespoke software.
  • Rationale: It is much easier to update a configured system than a customised one.
  • Recommended for: All organisations running the Now Platform; reducing customisation will result in faster, safer, and cheaper updates.

?

P21: Radical Transformation

  • Explanation: We will make bold decisions, encouraging ‘radical transformation’ beyond the limitations of the ‘As Is’ organisation / operating model.
  • Rationale: Sometimes a step-change is needed to make a significant difference. Considering the big picture can help to drive innovative and productive solutions that would otherwise be missed.
  • Recommended for: Organisations which have, in the past, made only small changes, looked for ‘low-hanging fruit’, and failed to change the status quo when given the chance. This is the most psychological of the Principles in this set; it effectively gives permission to leaders who might need a confidence boost, to encourage them to make the big decisions.

?

P22: Moments That Matter

  • Explanation: Workflows will be designed from a consumer perspective, across value chains, personas and user journeys to create ‘moments that matter’.
  • Rationale: Every interaction that a human has with the system is important. A great experience builds trust, confidence and the reputation of the system and the company. A bad experience has the opposite effect.
  • Recommended for: Organisations with a “Customer First” focus, those seeking to deliver?exceptional, perhaps bespoke, customer service.



Putting it into Practice

Organisations that do not have a set of Principles may consider adopting the whole set listed above, and adjusting them to fit their needs.

If an organisation already has a set of Principles, but they are only now moving to Platform operation, then their set will need to be adjusted to fit this new way of working. In this case, they can consider the set above in conjunction with their own set, and see if there are any of their old Principles that need to be removed or adjusted, and any new ones that can be included into their set.

In either case, if you are the EA or a consultant, take the list above and adopt a set of Principles that works for the organisation, with a view to review in six months, to see if the set is working well for them. Don’t forget, you will have to understand and include the Implications and Consequences of each Principle in the list, as described in Part 2 of this blog.

Used in combination with Governance, Architecture Principles are the best tool to shift an entire organisation into this mode of platform-oriented thinking. By positively influencing every design and buying decision, they help to shepherd the organisation away from chaos and towards order and discipline.

To be useful, the Principles must be used. This can be done though an Architecture Governance Board (AGB). Essentially, the Board adopts the Principles, and assesses all decisions against them. The AGB could reject proposals that contravene the Principles, or they might, by exception, choose to suspend one or more of the Principles so that a necessary change can take place.

To extend visibility and utility of the Principles, an organisation may wish to communicate groups of them to relevant teams, so that they can be considered up front in planning, outside of the AGB meetings. For example, the team in charge of designing user interfaces might be given all of the Principles in the “Experience” Theme above (Principles P3-P7), so that they keep them front of mind throughout their creative process. In this way, the Principles can be taken out of the ivory tower of the Architecture Repository, and become embedded into the heart and culture of the organisation, exactly where they should be.


About the Author:?Dr Michelle Supper?has contributed to the creation of eight international standards, along with other publications including white papers and guides. She is the EMEA Enterprise Architecture Advisor, in the ServiceNow EMEA EA Team, and the creator of the Guided Architecture methodology.?


Please join the conversation at the?ServiceNow Enterprise Architecture Forum


Russell Shear

Lead ServiceNow Consultant | ServiceNerd & Service Ducks Podcast co-host | ServiceNow MVP

1 年

This is great! Thanks for sharing..now to find part 1 & 2 ??

回复
Benton Bovée

Sr Enterprise Architecture Analyst/Modeler, Ontologist w/Active Secret clearance | Published Speaker | Mathematician, Logician | Recycled "that box" a long time ago

1 年

Lengthy and fair list--for this reason: Most recommendations are appropriate at various levels of enterprise maturity; and "the devil is in the details" for very large enterprises of enterprises.

Jon Johnson

Strategic Advisor

1 年

Thank you Dr Michelle Supper. My education continues. A great primer!

Allen Andreas

Senior Developer Advocate @ ServiceNow - Certified Master Architect (CMA), 6x ServiceNow MVP, Content Creator, Mentor, Military Veteran, and Passionate Knowledge Sharer!

1 年

This series has been great, Dr. Supper! Thanks for taking the time to write these blogs and sharing your expertise with us!

要查看或添加评论,请登录

Dr Michelle Supper的更多文章

社区洞察

其他会员也浏览了