Enterprise Architecture: An underrated Strategy Tool

What do you associate with the term Enterprise Architecture (EA)? Complex documents and diagrams produced by an architecture ivory tower? Too theoretical to be applicable to the real world? Many pages of rather theoretical framework descriptions?
If you reply to these questions with a straight “yes”, or you haven’t yet heard of the term Enterprise Architecture before, this is a real pity. In my opinion, every executive manager should know that the Enterprise Architecture discipline serves an important purpose in the overall management of a company and its IT. If the term EA already arouses positive emotions in you then you are in a lucky position and I hope you continue to make good use of the EA team in your company.

One of the typical problems prevalent in large and complex IT landscapes is the increasing technical debt which is the sum of quick and dirty solutions from the past that were never corrected and are becoming more and more painful. This debt calls for clean-up investments that have no immediate business value. However, due to strong cost and innovation pressure, everyone rather wants to jump ahead and build new stuff on top of antiquated IT architectures – thus further increasing the debt level. This ends up in growing dissatisfaction amongst all stakeholders because this debt not only costs a lot but also decreases flexibility.

I’ve seen many large IT debt reduction programs fail. Important reasons were always that the program goals were unrealistically ambitious and the program owners wanted to introduce all the necessary changes in one big step. After the stop of such a failed program, helplessness often prevails.
In such cases the EA discipline can help. An Enterprise Architecture structures your entire IT into smaller, manageable elements (domains) that are well aligned with the business. Furthermore, one major component of a good EA is a roadmap for the evolvement of a legacy IT into one that is future-proof. Such an EA roadmap helps to steer the evolvement by small and digestible steps.

I am very much convinced that proper Enterprise Architecture thinking is an indispensable tool for every organization to get a grasp on problems prevalent in today’s large and complex IT landscapes. But unfortunately many companies do not have EA departments with the right skills, or their EA skills are just too disconnected from the projects. Furthermore, the used EA frameworks and the resulting EA descriptions are often too complex and inflexible.

If you don’t know where to start using the EA discipline as a strategy tool, you should first initiate a project that establishes a simple EA framework and models the current and future IT landscape in a way everyone understands.
If you start your EA endeavor you should consider the following 6 hints carefully:

1. Start with a very simple framework. Like your IT, your EA should be flexible. The focus should be on the content, not on the framework. The framework should just outline the major elements of what EA consists of, e.g. models of the future business processes, the future IT landscape and related architecture processes. It should be a map that shows where you stand with the elaboration of the different prioritized components. We at Acrea have developed such a simple map that is an essence of other more comprehensive and complex frameworks (like for example TOGAF).
2. Model for reuse: Do not fall into the Microsoft Office trap. Use a proper modeling tool to avoid redundancies and ensure consistency.
3. Make sure executive managers easily understand the models: As models quickly become complex, make sure you can easily print out views on the model that every top level executive can understand. Show one of the print-outs to the CEO and tell him that this is the future business or IT landscape. If he gets enthusiastic of what he sees you are on the right track.
4. Involve the stakeholders: IT executive managers and business representatives must be involved in your EA efforts. Don’t make this an architecture ivory tower exercise. If the business owners and the IT executives find excuses to not attend the EA project meetings and workshops you should stop the exercise right away.
5. Progress quickly and iteratively: In order to get to a good first model version of the existing and future landscapes, spend no more than 3 months on it. Develop new versions every week during the project and review it with few key stakeholders in 2-3h workshops.
6. Evolve the description continuously: Once the EA models are “finished”, make sure people work with the models and the models get updated if something in the landscape changes.

If you follow this advice you will be able to benefit a lot from your first EA endeavor and can build on the developed models to define your strategic IT priorities.

However, be aware that defining an EA model of the target business and IT landscape is only the very first step towards a future-proof and highly flexible IT. You have to identify and initiate the right projects to make your EA vision happen and you have to excel at managing these projects.

EA is not a magic tool that can solve all your problems. But in my opinion EA - if done right and in a lean way - can deliver many business benefits.

Security software: Don‘t do it yourself

During my 20+ years of writing software, I admit to succumbing to my programmer’s code mocking reflex more than once. “I could have done that much more elegantly/simpler/better” is a common thought for a programmer while reading through other programmers’ code. A sentiment that is probably inherent to programming, since software code represents its author’s way of thinking, of structuring and solving problems: a highly individual streak, unique to every person. Immersion into the thought structure of another programmer often has literally a very uncomfortable feel to me, comparable to wearing my right-hand glove on my left hand. And there’s a great way to avoid this uncomfortable feeling: Just ditch the other person’s code, and start from scratch, my way. This is known as the not-invented-here syndrome, of course. Objectively, whether starting from scratch or using the existing, “foreign” code is more suitable depends on the situation. There is no right or wrong per se.

Make or buy?

As some programmers turn into managers, and some managers eventually into CIOs, the not-invented-here syndrome sticks with them: Many companies develop their own software when there are products on the market that would, at least at first glance, fulfill their requirements at least as well, if not better. Again, there is no right or wrong. Make or buy decisions typically take into account many factors, and people will probably always disagree while judging the available options. But when discussing those decisions, I often get the impression that especially former programmers try hard rationalizing a decision that is mainly rooted in that feeling so similar to wearing a wrong glove. Knowing where this is coming from, I tend to sympathize with them, and often favor specific, to the point in-house implementations over generic off-the-shelve standard products. But there is an exception: Security software.

Security software is different

This is an area where my internal judgment scale is highly loaded on the “buy” side. Why, you may ask, what’s so special about security software that makes me nearly always recommend buying over making? A few weeks ago, while having a program concept assessed by us, the customer asked exactly this. The question gave us a welcome opportunity to discuss the topic amongst ourselves, it helped us challenge and re-confirm our own perceptions. In the end we still agreed that in general, security software is better bought than made, for the following reasons:

1. Bugs: All new software comes with bugs. While this can be a nuisance in most areas, in security it can pretty much defy the whole purpose of introducing the software in the first place. Using something that has been around for a while reduces the risks of falling prey to a crucial bug.
2. Developers: “Security” is not just another requirement that can be jotted down on a card and put up on the Scrum or Kanban board. Like “Usability”, it permeates every aspect of programming, and requires a specific focus and sufficient experience to work around the many pitfalls of data insecurity. Programmers with this focus and experience tend to work in the security industry. Chances are there won’t be enough of them on your development staff.
3. Testing: Collective knowledge about good testing is ever increasing, with more and more teams adopting techniques like test-driven development, continuous testing, hallway testing, etc. But testing of security products adds a whole other dimension to testing. Typically, development teams for security software have put rigorous processes in place to ensure that what they release fulfills its purpose: is secure.
4. Penetration testing: You benefit from other users’ testing efforts: Not only does the manufacturer test very thoroughly. Many customers also perform penetration tests on their environment, some even regularly, up to several times a year. Information about detected vulnerabilities goes back to the manufacturer, who can solve the problem to the benefit of all the other users.
5. Vulnerability monitoring: Even the most ardent advocate of “do it yourself” development will rely on external libraries and components for some parts of his system. And these components and libraries may have security flaws themselves. Every day numerous vulnerability reports are being published by various organizations. Monitoring these reports, detecting the relevant ones and reacting appropriately is something a security software manufacturer dedicates considerable resources for. Our “do it yourself” advocate may easily miss some crucial hint that all his efforts of building a secure system are in vain due to a big gaping hole in a part he didn’t code himself. And most importantly, this is something that never stops, for the whole lifetime of the software.
6. Core business: From a business perspective, it’s most likely better if a company puts its software development efforts into developing core business solutions which help differentiate itself from its competition, rather than working on something that is certainly required, but will not help with generating business in the first place.

Of course this is all only true if the security software vendor in question can provide convincing proof that he is covering all these points.
So next time, when you find yourself having to decide whether that entry gateway or that authentication server should be bought or made, also consider to which extent you’ll be able to supply the project with adequately trained and experienced developers, sufficient testing resources, ongoing vulnerability monitoring for the whole lifetime, and to what extent you can live with newly found bugs in your system, and the absence of other users doing some of the testing and vulnerability finding work for you. And finally, decide whether security is part of your company’s core business, or just an auxiliary function.

Benefits of Agile Methods for large Corporations

In our daily life as consultants, we have observed quite some momentum within IT departments of large corporations to move towards agile software development methods like Scrum. Very often, this seems to be driven by IT staff who want to break out of the prison imposed by rigid development and project management processes. While this is understandable from the point of view of an engineer, it is certainly not enough to motivate such a change. This made me reflect about the potential benefits of agile methods for large corporations.

As a matter of fact, the more you think about it, the bigger the potential for agile methods gets. Large corporations suffer from inertia in general. Over time, their IT project management processes have become very heavyweight and are stuffed with overhead that does not at all contribute to running software that serves a business purpose.

During the outsourcing and offshoring hype, some companies invested themselves intensively in reaching outsourcing readiness. This has inflated process overheads even more and created a big obstacle in getting business requirements mapped into software within the requested time frame and budget.

Thus, for the business side, the internal IT appears to be very slow but expensive. Customers have to wait a long time for project deliveries that quite often still don’t meet the expectations. As a result, business managers often try to turn to suppliers of software solutions directly to implement software without going through internal IT project hell. But of course, such an approach gets them into trouble in many organizations.

Overall, this leads to a situation, where a lot of money is being spent, outcomes are unsatisfactory and both the business and the IT side are left frustrated.

Wouldn’t it be great to have shorter reaction times, quicker deliveries, higher quality, and even a better coverage of the business side’s needs?

As a matter of fact, this is exactly what agile methods like Scrum promise to achieve. Since a potentially shippable product increment is the goal of every iteration, deployment to production can be anticipated much earlier than for traditional waterfall projects. Therefore, the probability for successful project delivery is improved dramatically. An agile project can react much quicker to changing needs and requirements because prioritization is an essential part of planning every iteration. And such a prioritization approach also helps to reduce risks in an early stage of the project. In addition, since quality assurance is an integral part of development from day one, these solutions also feature a higher quality when they are shipped to acceptance testing.

Maybe the biggest benefit however is built into the role of the Product Owner. The Scrum method enables the business side to take the driver seat and actively influence the project direction in a very close collaboration with the IT team. This collaboration between the Product Owner and the Scrum team is much closer, more direct, and intensive than for a traditional business project manager.

Sounds all good? Well, it is. But of course there are some obstacles along the way:

• Skepticism regarding the feasibility of agile methods might be abundant especially in large corporations. Because the method has not proven itself internally yet, management might be reluctant to apply agile methods to the real risky projects which, as a matter of fact, could benefit most.
• Large corporations often promote various specialist roles. This is contradictory to small agile teams where generalists are key and specialists are only consulted selectively.
• Enterprise processes (e.g. for reaching the required milestone approvals) are somewhat conflicting with the iterative model of agile methods.
• HR approaches and reward structures focus on the individual rather than on teams
• The role of the Product Owner is difficult to staff.
• Budgeting processes usually demand a finalized project plan and a well specified delivery in advance.
• Regulatory requirements often assume a conventional project method with distinct phases and milestones.

To overcome these obstacles, a smooth transformation process is required. Along the way, it is important to keep the balance between the new, agile approach and adherence to existing enterprise processes and rules. Otherwise, the endeavor risks to be stopped by upper management prematurely.

We will address a possible approach for introducing agile methods into large corporations in one of our next Acrea blogs.

Are you fit for outsourcing?

Despite recent controversies, IT outsourcing is still thriving.

There can be many reasons why outsourcing makes sense. Increasing workforce flexibility and access to expert skills are prominent factors often mentioned, but cost saving is probably still on top of the list of arguments that lead to outsourcing projects.

However, I don’t want to analyze why companies outsource and whether they benefit from it or not. I am interested in the fact that many companies came to the conclusion that they want to outsource but horribly fail in successfully doing so.

Are you fit for outsourcing? That would be my first question to a CIO who made the decision to outsource a large IT project. Yes, the CIO would reply, but can you be more specific on what exactly you mean?

Because this is such an important question, we at Acrea have developed a framework to assess if a company is ready to outsource IT projects.

Obviously, “the vendor” is one of the categories on everyone’s checklist. It is an important aspect of outsourcing, as you have to find out whether the vendor is capable and knows his business. Project references need to be checked and skills verified – you would probably do this as part of an RFP-process.

We consider “culture” as another important aspect of outsourcing. Besides proximity, the culture category is a major reason why European companies offshore to Eastern or Southern Europe rather than to Asia – cultural gaps are hard to close and it might take years of joint teamwork until team members from distant cultures engage in true collaboration.

Other categories of our framework are more related to change management. There are many articles and books about leading change; one of my favorites is Kotter’s (1). Implementing a large outsourcing project is a big organizational change to many companies. So, why can companies ever forget about following the basic principles of organizational change? (E.g. the ones listed by Kotter). Do you have a clear vision of what you want to achieve in your outsourcing endeavor? Are you planning for and creating short-term wins? Do your employees understand the reasoning behind your move?

To revitalize your workforce is another essential step. How do you handle conflicts of interest in a situation where some key people are going to be made redundant and at the same time have to transfer their knowledge? And do your remaining employees have the skills to perform in the new roles required for outsourcing? For example, if you are not going to have your own developers anymore and many aspects of technology are managed by someone else, you probably need stronger project leaders and architects that are able to bring all pieces together. In addition, business analysis on your side will get much more crucial in order to make your business stakeholders happy with future deliveries. And last but not least, what about your workforce’s English speaking qualifications? Are they capable enough to negotiate with another (not necessarily native) English speaker, probably one with a different accent (2), over a noisy phone line?

In addition, the Acrea framework deals with IT processes and infrastructures. For example, in Switzerland bank secrecy laws (still) do not allow banks to send client-identifying data abroad for testing. In such a case, you clearly need a testing infrastructure (incl. test data) that is separated from your development and production environments and is accessible to the outsourcing provider.

To finalize the assessment there are more categories to analyze, among them are business process readiness, vendor management, external environment and you also have to verify how your project management processes fit with the ones implemented at your outsourcing provider.

I’ve touched on many topics and we’ve seen that of all the mentioned assessment categories only one is directly related to the outsourcing provider (“the vendor”). Isn’t it therefore quite obvious that a huge part of getting ready for outsourcing deals with your own company’s capabilities? Too much focus on the vendor can lead to disaster.

So when you start thinking about entering an outsourcing adventure, have yourself certified for “outsourcer readiness” first, before certifying your outsourcing vendor.

References:
(1) http://hbr.org/2007/01/leading-change-why-transformation-efforts-fail/ar/1
(2) http://www.youtube.com/watch?v=dABo_DCIdpM

An Alternative to Scrum of Scrums

In an earlier blog I talked about the importance of the team factor when scaling Scrum into a multi-team project. The method of choice is to build feature teams that are responsible for end-to-end delivery of a set of features requested by the product owner. One of the advantages of this approach is the reduced coordination overhead since there are less topics and issues to discuss in cross team meetings.

Now, how does this relate to the technique called Scrum of Scrums? Scrum of Scrums is essentially another daily Scrum meeting with a representative of each team attending. In the course of this meeting, participants are going through the usual Scrum routine. Scrum of Scrums is sometimes seen as a natural extension to Scrum and quite a few organizations are trying to perform it in their projects. However, Scrum of Scrums has some major drawbacks:

1. It is unnecessary. The approach with feature teams reduces the need for coordination because the teams can proceed with their work much more independently. In a corporate world where meetings are abundant it is always a good idea to get rid of unnecessary meetings.
2. It does not scale since once you have more than - let’s say - seven to nine Scrum teams the meeting grows too big. As an alternative parallel Scrums of Scrums could be set up which would then lead to the requirement for a Scrum of Scrums of Scrums (every day). Not a very attractive perspective.
3. It is a technique that does not say anything about the role of the product owner in such a setup.

So, how could an alternative approach look like?

First of all, the approach with feature teams does not really require an institutional daily meeting for coordination among the Scrum teams. Thus, well-structured projects can do without the Scrum of Scrums technique.

If there exists a justified need for coordination between the teams, this can be organized along topics and areas of expertise. Such coordination meetings can be held in regular intervals (e.g. weekly) or on-demand, but they certainly do not occur daily.

What’s essential: in multi-team setups the product owner’s role gets even more important, because this is the role providing structure and coherence to the whole endeavor. For up to 10 teams it has proven feasible to operate with one product owner and with a single product backlog. The product owner might be supported by feature team members or domain specialists but he remains in full charge for setting priorities and assigning feature stories to the teams.

In line with the increased importance of the product owner role, sprint planning is also becoming more significant. For multi team setups, sprint planning should be split into two phases. The first phase covers the allocation of sprint feature stories to individual teams. It is here, where the foundation for the minimal possible cross-team coordination need is being laid. The second phase can then be regarded as a regular sprint planning within each team.

Along the lines of sprint planning the sprint retrospective can also be split into two phases. In the first phase the teams perform their normal team retrospective. In the second phase, team delegates are going through a joint retrospective with a focus on the overall project.

As mentioned, the approach with a single product owner works for up to 10 teams. For even larger projects, a structure of well-defined product areas each with their individual “area product owner” can be put into place. In such a setup, the product owner is still a single person responsible for the overall product but in addition he is the leader of the product owner team consisting of all area product owners.

Assuming, that these larger projects are also structured into feature teams, no daily coordination is needed neither. Thus, our alternative approach to Scrum of Scrums can be scaled up seamlessly.

References:
Henrik Kniberg, Anders Ivarsson: Scaling Agile @ Spotify
Craig Larman, Bas Vodde: Scaling Lean & Agile Development

Cleaning Up Your IT: There Is No Silver Bullet

We know that a large part of today’s IT world is still based on so-called “legacy technology” and that the business side of large companies is often not happy about what they get from their internal IT. They see IT as an inflexible black box that costs too much. Moreover, in their opinion IT is a big heavy monster that is difficult to align with ongoing industry changes.

I strongly feel that this perception gap is not diminishing and that IT departments are heavily under pressure. Unfortunately, there is no silver bullet for cleaning up legacy shortfalls and improve the situation.

A few weeks ago, a friend from a financial services provider asked me if we could help them to clean up their IT mess. “You are an IT management consulting company after all”, she said. She was hoping that we could come in, clean everything up and fly away, like superman.

I told her that if we worked for them, we would first focus most of our work on enterprise architecture. We would typically suggest to move forward in line with the following steps:

1. Understand and analyze the current IT situation with regard to the business and IT strategy
2. Sit with business representatives to draw the business architecture, including a business domain map and critical business objects
3. Understand the existing application and data landscape and analyze its characteristics and issues
4. Define principles for how the landscape should be evolved. For example, one principle could demand strict alignment of the landscape with business domains and the data architecture’s alignment with business objects
5. Draw a long-term visionary state of how the landscape should look like
6. Identify migration scenarios and assess them based on the business and IT goals of the company
7. Choose one of the scenarios and come up with an implementation plan

In most cases, the business side of the company will accept the implementation plan. They understand that there is money to be invested until there is a cleaner landscape that is more flexible and costs less.

Seems straightforward? Well, it isn’t.

Never forget the implementation part. It’s true that a good enterprise architecture team knows how to approach the problem and could help to come up with a good plan. However, they are not implementing it.

Recently McKinsey (1), in collaboration with the University of Oxford, published some statistics about IT projects. They state that “on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.” This is not different with architecture projects. They can and sometimes will fail.

What should IT management do then? Of course, they should leverage their enterprise architecture teams in the best way possible; let them lead the work described above. But don’t stop there. Assign the best project leaders to your critical architecture implementation projects. Take responsibility. Show stamina. Even in case of reorganizations and responsibility changes, don’t stop in the middle of nowhere and keep going if they way forward still appears to be the right one.

“Unfortunately, we cannot provide you with a silver bullet”, I told my friend. “There is lots of work to be done. However, you will achieve your goals if you remember that the most important success factor in your enterprise architecture endeavor is your company excelling at core project management.”

(1) https://www.mckinseyquarterly.com/Business_Technology/Delivering_large-scale_IT_projects_on_time_on_budget_and_on_value_3026

The Neglected Product Owner

Scrum or agile development in general has been around for quite some time now, but it is still a hot topic in many organizations. Implementing Scrum or any other form of agile development successfully contains some challenges. This is especially true for large organization with many established processes, organizational structures and stakeholders.
Three of the most common mistakes that large organizations make about Scrum are connected to the Product Owner (PO) role:

1. Too many compromises are made in the staffing of the PO role
2. The POs do not get enough organizational support
3. The designated POs are rarely trained in Scrum, unlike many other employees

Let us visit these mistakes one by one:

Mistake 1): The larger an organization gets, the more stakeholders a project typically has. All of these stakeholders have opinions about the prioritization and the content of features. From the team’s perspective, this can be fatal: the more people give the team input about those topics, the more confusion is created. Therefore, the PO must be able to rally all the other stakeholders behind and be the single interface to the team.

Ideally, the PO directly represents the business. This gives her or him the authority to decide about the business’ priorities, but it requires also that the business side is committed to investing the time that is necessary to play the PO role well. Sometimes, daily interaction with the team may be necessary to ensure good progress. If this involvement is not possible, the PO should be another senior employee with a good link to the business side so that he or she is able to synchronize all stakeholders without affecting the team.

What is generally not a good idea from my experience is to use a business analyst as PO because this role typically does not have the levels of competence and weight in business decisions required by the PO role.

Mistake 2): We already saw that the PO needs the authority to make crucial decisions, namely about feature priority and content. This means that the PO needs strong management backing. Besides this, the PO needs other support from the organization: because those people that are good fits for the PO role are usually already quite busy, it often pays to give them support in describing the features and requirements in detail. In other words, they need business analysis support. From my experience, it works best if the business analysts are team members, but more than one model is possible in this area.

If the PO does not get this support, the typical consequence is that features and requirements get not described sufficiently (which significantly affects the team performance) and that the PO does not have enough time to do what he or she really should: keeping the big picture, coordinating stakeholders and setting priorities right.

Mistake 3): Typically, an organization that is starting to implement Scrum is sending some of its employees to Scrum training courses. Most of these training courses are for the Scrum Master role, which is the one role in Scrum which is responsible for making sure that the process is followed correctly. What is often neglected, however, is that the PO is probably the most important role in Scrum and therefore would need training just as much as anyone else.

Therefore, many POs are not really aware of how their team is supposed to work now and stick to their old working habits. This results in a lack of prioritization, a lack of content-wise leadership, confusion in the team, and an inefficient or even ineffective process after all.

As a summary, always remember: the Product Owner is a huge part of Scrum’s success. You should not neglect the importance of this role. Especially in large organizations, you have to take this seriously if you want Scrum to deliver on its promises. Making compromises with the Product Owner role can be an expensive mistake.