Aggregated enterprise architecture wisdom
One of the themes that came up in the Vlerick Business School session on EA-roadmaps was around how long it takes to learn how to develop the skills needed to do enterprise-architecture – and how and why to learn them,…
Enterprise modeling is an increasingly important topic for many organizations. It is widely recognized that models help understand the complex interplay of all elements that make up an organization. One of our clients uses “POPIT” (People,…
What’s the best metaphor we could use for the information collected in enterprise-architecture and related disciplines? The answer, I’d suggest, is a hologram. This is in part a follow-on to the post ‘What do we need from our EA tools?‘. What…
What’s the relationship between organisation and enterprise? In particular, how would we work with that relationship in enterprise-architecture? This one’s a follow-on from both ‘Fractals, naming and enterprise-architecture‘ and ‘Organisation and enterprise‘, and, more specifically, is a response to Len…
Over the past years many organizations have been working with an Agile method for software development, providing the design and development team with a particularly important role. Within several projects in which I was involved I had the chance to experience this from up close. In this blog I would like to share with you my experiences in working with the five top tips helping a design team efficiently and effectively perform within an Agile environment.
The first tip is all about creating a solid, high-quality base. This base will create a certain structure throughout the entire design process and will provide the scope of the process design. Next question on your mind now: But what does this base actually create? It is the key that the different stakeholders are familiar with the process design and are aware of its content. The process designer should bear in mind the possibility of minor adaptations taking place during the design track in the process design. Smaller parts of the larger whole are being developed. Because there is a framework present that gives guidelines and scope, a solid and flexible base has been designed. From which any adaptations to the process model can relatively easily be completed.
The second tip involves adding structure to the data present in the project, domain, subject area or department. Two data models can be distinguished, the first of which is the conceptual data model (CDM). The CDM contains all pieces of data (entities) present within the project, domain, subject area or department and any information on their mutual relationships. The different entities consist of attributes representing exactly which elements should be present within each entity. For example, which data (attributes) are required in an invoice (entity). Here we think of the amount, invoice number, name and address information, etc. The different attributes should moreover be further explored, where per attribute the following information should be specified.
The second data model we distinguish is the process data model (PDM). The PDM contains the data applicable to a specific process. The PDM is a minor building block of the much larger CDM. The data models act as input for the development team, providing them with a clear image of what it is they are developing. That is why it is the developer’s responsibility to provide the development team with very clear specifications (the range of values).
The third tip is about the collaboration with the most important stakeholders in the eyes of the design team. An important stakeholder for the design team is the architect. The architect is able to communicate which business and work processes can be distinguished and which requirements/parameters should be met. It is the architect who can clearly present the scope and the impact on the organization. The second important stakeholder is the development team. Make sure you as the designer are in direct contact with the developer, who can ideally provide you with further clarifying input, if needed. Other important stakeholders are the test team and management team. Invite the stakeholders to get involved in the design track and keep the lines of communication short. This will ensure clear communication with as few as possible unnecessary disruptions in the realization process. All too often, I see designers hand over their designs to the development team without any form of communication. This results in a portion of the idea being realized, but not the full package. By getting the developer involved early on and aiming for a better collaboration, he/she will have a much better understanding of what it is you’d like to see happen. In the user story specification of what needs to be developed is much more straightforward.
4. Make a framework for the conventions and concepts
The fourth tip involves the making of clear arrangements around the process conventions and concepts. Within the software development team, it is key that the different members clearly decide on the specific criteria to be met by the process model and what the model should look like. Those agreements should ideally be compiled in a convention document. Many organizations do have such a convention document in circulation. It is expected of the design team to apply these conventions in the modeling of the process designs. Just as important is it for you to regularly test your process model against the agreed conventions. Such a test will ensure the consistent implementation of the conventions, moreover allowing the stakeholders to easily recognize and understand the models. These are familiar concepts to them, after all. Which brings us to the wording used within the project and process design. The misinterpretation of certain concepts could potentially be the cause of much hassle. Wise would be to draw up a list of commonly used terms. Make sure an up-to-date list regularly finds its way to the stakeholders. These clear and unambiguous process conventions and terminology list can only improve the collaboration between the design team and its stakeholders.
The fifth and last tip covers the documenting of all documentation being developed within the process design. In this tip, I do not talk about all the documentation in de design track but only about the documentation from the process design. In my experience, Agile and Scrum environments can do much better in documenting the documentation from a process design. This is often a result of the lack of time provided to organize the documentation for a process model because of the speed with which development is announced. Even afterwards, the documentation is rarely brought up to date, as new projects have already started. Any realized projects are unfortunately minimally documented. If management would want to review any of these, this simply would not be possible due to a lack of documentation. From this point of view, one could argue for the importance of keeping relevant documentation up to date and to schedule the time to complete this. As a designer, regularly check if all documentation is complete and if needed, request the extra time to take care of this.
Hopefully this has given you more insight into the success of a design team. My tips are intended to help pinpoint where exactly things stray within a design team, and to guide any designer in preventing such situations. I will recommend the designers to discuss above tips internal with their colleague process designers. For the individual designer, start communicate with the stakeholders. It is easy to realize because you can contact the stakeholders easily. I have gained my experiences from working within several organizations and branches and would be delighted to hear your thoughts too.
What naming do we need, when we’re doing architectures for every part of the enterprise? Yeah, I know this is another one that I go on and on about, but it’s just too bad: we need to resolve this one –…
We’ve recently explored here the transition from product to service – but what about the other way round, from service to product? (Many thanks to Michael Poulin for reminding of this point.) As far as I understand it, product and…
I guess most readers of this blog know that Ireland went through a massive bust in 2008/9. The primary cause was a massive building bubble. And because the economy was dependent upon building related taxes, the crash was brutal. One of the side effects of the bubble was that building standards suffered. In one extreme case a block of apartments was constructed with no fire safety protection! There were many, many more prosaic examples. In my own case I had building works completed that had to be completely reworked within a couple of years! The reasons for the low quality were complete lack of governance. In the boom times many people set-up without adequate skills and many developers over-committed to deliver more work than they could manage competently. In Ireland, unlike say the UK, there was no independent building inspection regime. Architects merely had to give approval for work to proceed at the major stages. There was no independent oversight.
Today in the Agile project world the idea of self-governance is pervasive. But the parallels with the Irish governance regime in the noughties is too close for comfort. The Agile principles guide that projects should be built around motivated individuals, given the environment and support needed and trust them to get the job done. Further valuing working software over comprehensive documentation is effectively encouraging teams to dispense with transparency and traceability. While this may work in small scale environments, in a large enterprise the idea that all teams will be highly skilled, properly resourced and motivated contradicts general experience. So in many large organizations conventional governance is still a requirement that can be highly detrimental to the efficient Agile process.
In my last blog post I described a new Agile governance model that addresses the empowerment question with:
a) A defined Agile governance model
b) Defined principles and reference architecture that establish ways of working together with articulation of business value
c) Automation systems that progressively incorporate the principles and reference architecture into frameworks, tooling, design time platforms, deliverable profiles and knowledge management systems.
d) A Community of Interest (CoI) responsible for the governance system and communications
e) A communication system that ensures Agile projects are fully implementing the governance system, and providing at least retrospective feedback to the CoI that contributes to a common asset base as well as practice maturity.
And in this post I want to explore further the organizational issues. In the image I show there are three primary stakeholders in the Agile process. A Design Authority (DA), the Community of Interest (CoI) and everyone else; let’s call them the Crowd. And what’s really important is this is not a conventional hierarchy. The Crowd, developers, architects, product owners and business analysts are the drivers of the process, engaged on business improvement delivery projects. The CoI are also part of the Crowd insofar as they are also engaged on delivery projects, but they are individuals that have a further role of taking responsibility for coordinating consistency of the approach taken by delivery teams. As shown the CoI will be responsible for reference and enterprise/domain architecture and have an approving role for solution architecture and design, platform components and factory configuration. And the key point here is that all of these key deliverables start by being crowdsourced. The delivery teams are in the best position to establish solution architecture and design. The delivery team member with a CoI role is responsible for identifying and promoting candidate components of reference architecture, the design platform etc to the collective CoI.
The DA is different. It’s still not hierarchic, but it does approve demand shaping decisions, reference and domain architecture. This generally happens in response to delivery project concerns, for example when there are affordability or timescale issues with “doing the right thing”. You know the deal, if we don’t worry about technical debt, we can deliver on time and budget. But if we address the bigger architectural questions, and deliver solutions that will reduce complexity, reduce operating and maintenance costs etc, then the delivery date will be pushed out and additional resources required. Frankly this is the right time to address the value of architecture, because the questions are real.
So what I have described here, and in the last post, is an evolving governance model in which the definition of “self” is stretched a little to encompass the role. The Crowd has a major role in informing the requirements for policy and architecture as required for specific projects. The CoI are responsible for synthesizing these requirements to meet some broader, longer running remit and the DA guides on bigger questions of architectural compliance from a strictly business value perspective. The Crowd and CoI are also responsible for automating policy wherever possible; selecting exemplar solution components for platform and factory implementation, so that the very best solution components become reusable as patterns, configuration items, coding standards, services etc.
Whether it’s in a building or software development context, simplistic self-governance doesn’t work in complex enterprise situations. However understand the roles and responsibilities, work bottom up with Crowd sourcing and you may just motivate a very large team by enabling them all to contribute to the greater good.
See Also: Agile Governance
I guess most readers of this blog know that Ireland went through a massive bust in 2008/9. The primary cause was a massive building bubble. And because the economy was dependent upon building related taxes, the crash was brutal. One of the side effects of the bubble was that building standards suffered. In one extreme case a block of apartments was constructed with no fire safety protection! There were many, many more prosaic examples. In my own case I had building works completed that had to be completely reworked within a couple of years! The reasons for the low quality were complete lack of governance. In the boom times many people set-up without adequate skills and many developers over-committed to deliver more work than they could manage competently. In Ireland, unlike say the UK, there was no independent building inspection regime. Architects merely had to give approval for work to proceed at the major stages. There was no independent oversight.
Today in the Agile project world the idea of self-governance is pervasive. But the parallels with the Irish governance regime in the noughties is too close for comfort. The Agile principles guide that projects should be built around motivated individuals, given the environment and support needed and trust them to get the job done. Further valuing working software over comprehensive documentation is effectively encouraging teams to dispense with transparency and traceability. While this may work in small scale environments, in a large enterprise the idea that all teams will be highly skilled, properly resourced and motivated contradicts general experience. So in many large organizations conventional governance is still a requirement that can be highly detrimental to the efficient Agile process.
In my last blog post I described a new Agile governance model that addresses the empowerment question with:
a) A defined Agile governance model
b) Defined principles and reference architecture that establish ways of working together with articulation of business value
c) Automation systems that progressively incorporate the principles and reference architecture into frameworks, tooling, design time platforms, deliverable profiles and knowledge management systems.
d) A Community of Interest (CoI) responsible for the governance system and communications
e) A communication system that ensures Agile projects are fully implementing the governance system, and providing at least retrospective feedback to the CoI that contributes to a common asset base as well as practice maturity.
And in this post I want to explore further the organizational issues. In the image I show there are three primary stakeholders in the Agile process. A Design Authority (DA), the Community of Interest (CoI) and everyone else; let’s call them the Crowd. And what’s really important is this is not a conventional hierarchy. The Crowd, developers, architects, product owners and business analysts are the drivers of the process, engaged on business improvement delivery projects. The CoI are also part of the Crowd insofar as they are also engaged on delivery projects, but they are individuals that have a further role of taking responsibility for coordinating consistency of the approach taken by delivery teams. As shown the CoI will be responsible for reference and enterprise/domain architecture and have an approving role for solution architecture and design, platform components and factory configuration. And the key point here is that all of these key deliverables start by being crowdsourced. The delivery teams are in the best position to establish solution architecture and design. The delivery team member with a CoI role is responsible for identifying and promoting candidate components of reference architecture, the design platform etc to the collective CoI.
The DA is different. It’s still not hierarchic, but it does approve demand shaping decisions, reference and domain architecture. This generally happens in response to delivery project concerns, for example when there are affordability or timescale issues with “doing the right thing”. You know the deal, if we don’t worry about technical debt, we can deliver on time and budget. But if we address the bigger architectural questions, and deliver solutions that will reduce complexity, reduce operating and maintenance costs etc, then the delivery date will be pushed out and additional resources required. Frankly this is the right time to address the value of architecture, because the questions are real.
So what I have described here, and in the last post, is an evolving governance model in which the definition of “self” is stretched a little to encompass the role. The Crowd has a major role in informing the requirements for policy and architecture as required for specific projects. The CoI are responsible for synthesizing these requirements to meet some broader, longer running remit and the DA guides on bigger questions of architectural compliance from a strictly business value perspective. The Crowd and CoI are also responsible for automating policy wherever possible; selecting exemplar solution components for platform and factory implementation, so that the very best solution components become reusable as patterns, configuration items, coding standards, services etc.
Whether it’s in a building or software development context, simplistic self-governance doesn’t work in complex enterprise situations. However understand the roles and responsibilities, work bottom up with Crowd sourcing and you may just motivate a very large team by enabling them all to contribute to the greater good.
See Also: Agile Governance
.jpeg)
Digital business has put new demands on Enterprise Architecture professionals to make the connection between technology’s constant disruption and its impact on business goals and outcomes. According to Gartner, EA teams that do not refactor their skill sets from technology artifact generation to business outcome realization will marginalize their value and struggle to remain relevant.
Today’s Enterprise Architect
Today’s EA practitioners fall into two primary camps: the vanguard enterprise architect and the foundational enterprise architects. An innovation driver, the vanguard architect deals with technology disruptors and enterprise connectivity, while the foundational enterprise architect maintains enterprise technology and the systems of record.
While currently only making up 10 percent of EA organizations, the vanguard practitioner is emerging as the leader of the pack with an ability to make and communicate business decisions that navigate digital business and technological disruptors. Gartner predicts the number of these practitioners will reach 20 percent by 2016.
The Future’s Enterprise Architect
As we’ve talked about in recent posts, the future of EA puts the enterprise architect in a leadership role by driving strategy based on business goals and direction. Deliverables for this emerging breed of enterprise architect include strategic guidance from the C-suite and down, roadmaps, principles, standards, and best practices.
The diverse skill set of this version of the enterprise architect links digital business, social connectedness, and technology.
To build out these types of teams, organizations are looking to millennials who retain these competencies due to early exposure to technology and the digital world.
This is not to say that historical knowledge of EA practices and an understanding of modeling and IT structures is no longer valued, but skill sets need to evolve with business requirements. The new face of EA will succeed through fresh, big picture thinking combined with traditional application of models and data.
“The “New Face of EA” in many ways requires a “New Generation” of Enterprise Architecture professionals. The primarily IT-focused professional of the past — and some would argue the present — alone will not get the profession to where it needs to go. We need EA organizations comprised of people who understand business at least as well as technology with a reporting structure outside of IT. Creating this type of professional requires educational system changes, while also fostering more interdisciplinary undergraduate and graduate programs.”
Brian Cameron, Associate Dean of Professional Master’s Programs, Pennsylvania State University, Smeal College of Business
Today’s reality is that pretty much any capability the business dreams up will require the technology department to figure out how to deliver it. This means an understanding of how this technology will not only impact its users, but the entire business ecosystem will be a highly valued contribution… and the New Enterprise Architect is best poised to deliver that insight.
What is an enterprise? Perhaps more specifically, what is ‘the enterprise’ in enterprise-architecture? (Quick TL;DR summary: in enterprise-architecture, ‘the enterprise’ is not the same as ‘the organisation’, and is always larger in scope than just ‘the organisation’. Confusing those two terms, or treating…
What’s the relationship between product and service? How does that relationship work in practice, within a service-oriented enterprise-architecture? What started this one off was this much-referenced comparison: (My apologies, I don’t know who to credit for this image – perhaps…