Author: Shan Gu

5 Ways to Solve the Talent Crunch

It is undeniable that there is a massive talent shortage within the software industry right now. This is a problem that long predates the more recent, universal worker shortages and is a problem that will continue to get worse as more of the world moves towards living and interacting digitally.

Talented, inquisitive people are the core of Foci Solutions. We are nothing without the awesome developers and engineers who’ve chosen to build their careers with us. We return that loyalty with as much support and mentorship as we can provide. We’ve learned a great deal since we were just four people crammed into a small office. We’ve become extremely fortunate and successful at attracting, developing, and retaining top software talent. I want to share some of those lessons and observations both at the broader ecosystem level and as individual business operators.

#1 – Build, Don’t Buy

This is simply the reality of being a small company. We will not win in a bidding war for top talent with the likes of Google, Amazon, or Shopify. We hire team members based on their potential and not on the number of years with a particular technology and we invest in them to build them into better software engineers. This is effective as technology is constantly evolving and changing, but the core patterns, theories, and behaviours remain fairly constant. A junior team member who is highly curious, has an aptitude for learning, has good engineering instincts and behaviours, and is a good communicator can become highly effective very quickly with the right support system.

There’s also the simple mathematics of supply and demand. Doing a quick search for Junior Software Developer opportunities in Ottawa on a major job search platform returns around 20 results. Doing the same search for Senior Software Developer turns up around 280. There just aren’t 14x the number of senior developers as juniors. And there never will be. So if you’re trying to hire for experience, you’re competing in a low supply and high demand market. Simply put, investing in junior resources and building them up to be awesome makes mathematical sense.

#2 – Hire Teachers, not Just Doers

Hiring senior resources and asking them to spend the majority of their time writing code can provide immediate impact and productivity gains but to amplify their value over the long term, we want to tap into all of their years of knowledge, experience, tips and tricks and distribute that throughout the team. Having seniors spend more of their time acting as mentors and teachers will create a force multiplier effect, making your entire team stronger.

To do this effectively, focus more on their communication styles and willingness to mentor others rather than just their technical skills when interviewing for senior candidates, include mentorship of junior team members into their job descriptions and (most importantly) provide them with the time and the tools to do those things.

#3 – Communicate, Communicate, Communicate

Most of us are not great at identifying and articulating our learning and growth needs. This is particularly true for people working in task and productivity driven jobs like software development. It takes a tremendous amount of self-awareness to know what we’re not good at, let alone figure out what kinds of support we need to fill in those gaps. Consistent and frequent communications allows the team to collectively work through issues and identify things that each person can learn and develop to improve.

Implement formal code reviews, pair-programming, 1-on-1’s, quarterly learning reviews, basically any opportunity to talk about challenges, celebrate successes, and figure out how to do things better. This takes a lot of time, so it’s best to allocate budget to this. It will pay off in dividends.

#4 – Interview for Knowledge, not Skill

We’ve tried all kinds of things in an attempt to assess technical skills during the interview process such as live coding challenges and take home exercises yet never found a strong correlation between how a candidate performed at those activities vs how they performed on real projects. Even worse, those activities were extremely time consuming to administer and caused a lot of candidates to simply drop out of the process. What we realized is that asking someone to explain their code or how they solved a technical problem is a much better indicator of knowledge than a high-pressure, staged coding exercise.

Ask to see code that they’ve done instead, and get them to walk through it with you. Ask them to explain their design decisions, their thinking when they built it, and what they would do differently. You want to see if the person understands basic software concepts and principles, can think critically, can articulate technical concepts, and is able to learn from their mistakes. If the principles and concepts are there you can always teach them how to build a specific algorithm or use a specific framework.

#5 – Engage with Academic Institutions

Alright, this is a bit of a macro activity and frankly we haven’t been very successful at it. Universities and Colleges curriculums cannot keep up with the concepts and skills that the software industry needs for new grads to hit the ground running. We, as industry leaders, need to engage with academic institutions in our communities to help them modernize their programs.

Sure, there will always be a need for people to know Assembler and how to build Compilers, but that is not what the majority of the software industry needs today. If Computer Engineering and Computer Science programs were teaching about cloud computing models, 12-factor application design, Test Driven Development, APIs, application security, infrastructure as code, and other fundamental concepts that are widely adopted in modern software organizations their graduates would be better able to transition into real software roles.

The talent crunch can’t be solved by throwing money at it and having senior resources play musical chairs among the firms with the deepest pockets. We can build a better and more sustainable ecosystem of high quality software engineers by: constantly investing in their development; freeing up the flow of experience and knowledge within our teams; emphasizing the aptitude for teaching and learning rather than pure technical skill; and working with the academic community to ensure graduates entering the workforce have more relevant and up to date skills.

  • Shan
  • Gu

Want to be a Digital Enterprise? Build More Software!

“COTS-first”, “Why build it when we can buy it?”, “Custom development is expensive”, “We’re not a software company” were all slogans that were hammered into my head during the first half of my career working for a large global consulting firm. They were and are still the prevailing wisdom in the IT industry and when looked at it purely from a cost/benefit perspective, they’re easy to justify.

Those sentiments are also directly responsible for the widening gap between organization’s IT capabilities and their digital aspirations. The philosophy of outsourcing software IP is exactly what led the banking and government sectors to be woefully slow in implementing digital services. It’s why the major banks, despite their deep pockets, are having such problems catching up with small Fintech startups.

So how did we get here?

The Great Divide

For as long as I can remember, IT and software industries were considered separate and only loosely overlapping. Software companies did all the complicated engineering and computer sciency stuff that made tools, and IT practitioners installed and tailored the tools into enterprises like Ikea furniture.

Early CIO’s reported to the CFO in most large enterprises and the focus was on how to get systems deployed with the least amount of money possible. “On time and on budget”, “OpEx and CapEx efficiency”, “ROI”, and “cost recovery” were what occupied IT executive minds.

The Digital Reality

Companies like Amazon and Netflix have shined a light on the new digital reality: software is the business. They didn’t adopt the traditional thinking that software was some capital asset to be treated like a cost centre on a balance sheet, but rather a revenue generator and competitive differentiator. The focus shifted instead to “agility”, “speed to market”, “resiliency and reliability”, “scalability”, “security and integrity”, which are more closely aligned to how organizations think about their core business offerings.

The Convergence

The move to digital has pushed enterprise IT shops closer and closer towards the practices, philosophies, and skills of the software industry. Concepts like Agile, Extreme Programming, and Domain Driven Design which were widely accepted within the software industry by the mid 2000’s are finally being seen as table stakes for the digital enterprise in 2020. Sometimes we’ve even given them new names like DevOps and Microservices to make it feel like the IT industry invented these concepts.

The increasing maturity and variety of software frameworks are starting to blur the line between custom development and COTS as developers can now do a lot more with a lot less code. Cloud takes this even a step further where everything ranging from a logging service to a CRM can be provisioned and interfaced with via an API through a little bit of code. The short of it is that enterprise can’t get away from building code anymore, but they also don’t have to build as much of it to deliver the same features as 20 years ago.

The Gap

The problem that exists today is, to state it bluntly, that enterprises don’t know how to build software. Decades of prioritizing buying over building has created IT departments heavily geared towards project management, requirements gathering, system administration, and configuration of various COTS tools using whatever proprietary vendor technologies. There may be a few intrepid developers responsible for gluing all this mess together and keeping it all running plus some plucky web dev teams that push out wave upon waves of web forms. But the gap to actual modern software development is huge. And this gaping chasm is what most enterprises are being forced to cross in their shift towards a digital economy.

Crossing the Chasm

I think this is the first time since my 2nd year Marketing class that I’m actually using this phrase. Enterprises must invest in building software, especially related to the delivery of digital services. Not because it’s cheaper or less risky than buying it, because in most cases it’s not. But because that’s the only way to actually build up the type and scale of software development capacity needed to transition to digital.

We’re not just talking about coders, but all the surrounding disciplines that enable successful software delivery (e.g., product owners, UX designers, project managers, executives, testers, platform ops, security). Even accounting models have to change to stop treating software as a depreciating asset and instead as a line of business. Organizations have to fully embrace the reality that going digital means running a software company.

The new reality is that software is a part of any digital organization’s core business. And experience has taught us that any organization who outsources its core business will never be competitive.

  • Shan
  • Gu

Stop Talking About Cloud

Yes, this is an odd sentiment to have as a Cloud-native software company but hear me out. We spend a lot of time talking to organizations about adopting Cloud concepts and approaches. The large majority of the discussions land in one of two categories:

  1. Help me move stuff to the Cloud to save money and time. This line of discussion quickly focuses on technology and tools:
    • Which Cloud should I pick?
    • Should I use Kubernetes?
    • SaaS or PaaS or IaaS?
    • What are the Cloud equivalents to my current stack?
  1. I’m skeptical of Cloud, so help me understand:
    • Is Cloud secure?
    • Will it actually save me money?
    • What about vendor lock-in?
    • Will my stuff run in the Cloud?
    • How much work will it be to move?

When we dig deeper with our clients to try to answer these questions, we always end up exploring more fundamental IT organizational challenges instead. Why? Because talking about Cloud is talking about the destination rather than whether we have the capabilities to make the journey. 

Imagine if a hockey team focused on moving into a new arena to improve its record and attendance rather than investing in its coaching staff and players? 

That’s exactly what we’ve been doing in the IT industry: being fixated on where our apps run rather than how we build and operate them.

“Modern Software” not just “Cloud”

Cloud isn’t some revolutionary invention that just appeared one day. It is effectively an ongoing refinement of hosting technologies and business models that are enabled largely by two things: scale and automation. These are the same things that drove the Industrial Revolution. Therefore we should be viewing the rise of Cloud being indicative of the modern industrialization of the software industry.

So instead of talking about how we get to Cloud, we should really be talking about how we build modern software and what that really means.

What Does Modern Software Development Mean?

Traditional or legacy software principles were developed during a time where compute power was limited and optimization of CPU performance, memory, and storage was top of mind. In modern software development, we recognize that compute is cheap and so we should optimize for business outcomes instead. How quickly can we respond to changing user needs? How well can we scale if our software is wildly successful? How do we remain resilient to failures? How do we build and maintain user confidence? How do we control development costs with constant change?

Just like how the Industrial Revolution changed manufacturing, modern software means industrializing our process of building software along the same lines:

  • Focus on software frameworks rather than programming languages to minimize “building from scratch”
  • Automate the mundane and repetitive (e.g., CI/CD, test execution)
  • Design for modularity
  • Build for scale
  • Exhaustively test for quality
  • Constantly iterate for improvements and allocate budget for it
  • Instrument the process and measure velocity; then improve it
  • Design assuming failure will happen
  • Assume and embrace constant change

Development and Operations are Intertwined

Many of the operational issues associated with traditional software development (e.g., chronic underfunding, tech debt accumulation, rust out, performance degradation) can be attributed to having too clear a delineation between development and operations. User needs, organizational priorities, and technologies are constantly changing. Therefore software development is never done. 

Operating a software solution and developing new features or addressing technical debt must be an ongoing and integrated process rather than distinct activities. Concepts like DevOps aim to address this, but the change in approach involves the entire organization down to how software investments are funded.

Build People Not Widgets

Cloud migrations or app modernization initiatives are too often structured as outsourcing engagements where organizations feel the only viable path to success is to hire some experts to do it for them. This is frankly a shortsighted approach and I have yet to see it really work out, especially over a year after the project ends. Client teams are often left woefully unprepared to inherit and support the hundreds of applications which they’re no longer familiar with.

These big programs should be seen as an opportunity to upskill and reskill the organization’s technology teams instead. Expert teams can be brought in to work with the organization’s internal teams in a player-coach capacity to adopt modern software development methods and tools. The organization’s IT governance and management processes should also be adapted for modern software outcomes such as agility and velocity.

Let’s stop talking about Cloud and talk about investing in our people’s ability to build modern software instead.

  • Shan
  • Gu

A Realist’s Guide to Culture Change

The phrase “we need to change our culture to be successful” has become a punchline for any executive pitching ambitious visions and transformation initiatives, IT-related or otherwise. What is unfortunately less common is any mention of how such a change in culture will happen and how to know when this ideal future culture has been achieved.

Foci is by no means a change management firm nor do I profess any kind of expertise in human behaviour or organizational theory. We are however experts in helping organizations adopt new technologies and methods where culture is an unavoidable challenge. Based on our experience in the trenches, I would like to offer a realist’s perspective on what taking on “culture change” means and what one can expect when committing to this lofty goal.

Culture = People

We can’t talk about culture without defining it first. Culture is an abstraction of what the default behaviours and tendencies of a group of people are. Those behaviours and tendencies are either learned and developed in reaction to how an organization is built and managed, or inherent in the people that are being hired.

When an organization sets out to change its culture, it must accept the reality that it will likely result in a turnover in people. The culture that you desire won’t resonate with everyone in the organization. And a strong culture is built by people who naturally buy into it rather than by trying to hard sell it to someone. Therefore, it’s best to ensure that you are prepared to deal with an increase in turnover and hiring as a part of this commitment rather than assume that a new culture can be achieved without big changes to the workforce.

Culture Requires Nurturing

Executives can’t really dictate the culture of an organization the same way parents can’t really dictate the personalities of their children. An organization’s culture develops based on how people react to and are motivated by that organization’s structure, management style, processes, facilities, compensation model, other employees, and countless other factors. Any attempt to try to define a new culture without looking thoroughly at all aspects of the organization which enabled the current culture would be flawed.

Instead of asking how individuals can adopt the desired behaviours, the organization should ask what aspects of its current structure, policies, compensation, governance, rituals, and general work environment are contributing to the undesirable behaviours and then work to address those. For example, if an organization desires a culture of innovation, budget and approval processes will have to be updated to allow for more experimentation, frequent changes in project parameters, and faster decision making. This is a very organic and fluid process, so set realistic expectations and adapt the plan to how the people are reacting to the changes.

Stress = Negative Behaviours

High stress situations tend to push people to exhibit more basic survival instincts such as territorialism and combativeness. It is extremely difficult for people to adopt more desirable behaviours such as collaboration and transparency or take extra time to think about innovative solutions when timelines are aggressive and budget is tight.

People take time to learn new ways of working and making decisions. This means that efficiency and output will drop before recovering and even improving over the longer term. Project budgets and timelines must account for this and give people enough time to learn the new behaviours and repeat them enough times to become ingrained. It’s the classic “slow down to speed up” adage.

Change Starts at the Top

I am constantly surprised by the number of organizations treating culture change as an exercise whereby the executives look at how they can fix their workforce without also looking at their own behaviour. The culture of an organization is representative of how executives have made decisions over time.

If an organization wants to encourage a culture of taking responsibility, then executives must reflect this by taking actions such as increasing delegation of decision making and making their compensation more outcome-based. If more collaboration is desired, then open door policies must be adopted. Executives can’t just be the champions of change, but also become the examples of the desired culture themselves. The “do as I say and not as I do” philosophy doesn’t work here.

Achieving Success

We are extremely proud of the culture we’ve achieved at Foci. We’ve been deliberate in designing our organization and been very lucky in the type of people we’ve attracted and hired. Here are some of the things that we’ve done and learned about building a strong and innovative culture:

  1. Hire executives with diverse opinions and approaches, but very similar values. Your leadership should have different approaches to solving problems, but should see eye-to-eye on the organization’s core beliefs and philosophies;
  2. Hire for culture fit over pure technical acumen. It’s much easier to teach technical skills than modify behaviours;
  3. Constantly adjust and refine organizational processes and policies. Organizations and the people within them evolve over time. The processes and policies have to be tweaked to account for that;
  4. Create a relationship of mutual trust between our people and the company. Giving people the room to make decisions and exercise judgement encourages a sense of responsibility and ownership. Treat your staff like responsible adults who can make good decisions;
  5. Compensate people based on what you value in your employees. If you want a team that’s constantly upping their game, then compensate for personal growth and skills development;
  6. Invest in people. It’s not just training and some formalized mentorship program. Give people the time, resources, and the infrastructure needed to connect, collaborate, and share knowledge.

Culture change is hard, but by no means impossible. It takes a lot of commitment, attention, investment, time, and patience. By recognizing that the change is really building an organization that nurtures the desirable culture, “we need culture change” will become an achievable call to action rather than just an executive punchline.

  • Shan
  • Gu

What’s Your Organization’s Rocket Fuel?

The conversations I regularly have with clients, other executives, and my mentors are usually around “what’s your org’s vision?” or “what do you want your org to do”. Foci has gone through a tremendous period of growth and change over the last 12 months and the answers to those questions seem to be ever changing. This has led me and the rest of the management team to have some very interesting discussions around how we define Foci and our purpose.

The “what” and the “how” doesn’t matter

Photo by John Baker on Unsplash

Regardless of how well thought out your vision or strategy is, the reality is that $%*@ happens. Your clients can change their mind, you may lose some key contracts, the market will evolve and change, competitors will emerge, or you may not be able to get that unicorn architect/developer to run that world-changing product you want to build. And every time you have to make a pivot to adjust to those changes, it can be a very painful experience, both for you and your team.

The identity of an organization is very important, especially if you have a strong team culture like us. Team members imprint themselves onto that identity and subconsciously use it as a reference point for their everyday work. We started life as an Oracle Fusion Middleware company, then became an Architecture and Integration company, and now we’re doing more Cloud-Native custom dev with a broader range of system integration and program management services. Each of those shifts in focus created quite a bit of disruption in the team. People asked “Wait what? I thought we were doing the other thing? What does that mean to our existing projects? Will we stop doing the other thing altogether?” These were all fair questions, but after working through it all, we noticed that none of it actually impacted our team culture or our core behaviours.

What we took away from this were 2 things:

  1. What you did as a firm or how you did it had very little alignment to your culture.
  2. Our people are very emotionally connected to Foci’s identity and feel any change in that identity keenly.

It’s all about the “why”

This naturally led us to look at why our folks joined Foci and what made them excited about coming into work each day. Turns out no one was really driven by the prospect of writing thousands of lines of C# code, installing and configuring Oracle SOA Suite, or creating a stakeholder engagement plan. Sure, those things interested people, but they weren’t really core motivators.

We ended up landing on 2 aspects of motivation that were the most important:

  1. What brings you the most satisfaction (e.g., solving a problem, having an impact, getting recognition, seeing something you’ve built be used)
  2. What is your metric of value (e.g., complexity of the problem, number of people impacted, transaction volume, financial savings)

Problems are our rocket fuel

We always joked about having a generic tagline like “we solve problems” (it’s on our website) because we were constantly evolving the business. Appropriately that turned out to be the answer. What we realized is that our entire team and our hiring processes all coalesced around the core desire to solve complex and interesting problems. We weren’t motivated by how many people were using an app that we had developed or whether the systems we helped our clients build were processing 100 or 1,000,000 transactions a day.

The thing that gave us all a real sense of accomplishment and gave us that little shot of dopamine we humans naturally crave was when we were able to solve a problem for our client. The bigger the complexity greater the satisfaction. As long as we had a healthy supply of complex and interesting problems to feed our team, we could go anywhere.

The destination and the things you do to get there will always change over time. The things that motivate and drive you to move forward are more constant and core to your being. Defining your organization based on the goal you want to achieve or the tasks that you do makes every pivot feel like an identity crisis. Putting in the time to identify the rocket fuel that constantly propels your team forward creates a solid corporate identity to anchor against regardless of the path your organization decides to take. Interesting problems are our rocket fuel. As long as we as a management team ensure that our team has a steady flow of interesting problems to solve, we can have every confidence in Foci’s ability to achieve any goal that we set for ourselves. Until we change our mind, of course.

  • Shan
  • Gu

IT Organizations Need to Practice More, Dunk Less

Whenever I walk into a new client, the first things I hear from the Technology Executives are typically: “We need to modernize”, “We need to transform”, “We need to adopt <insert trendy tech buzzword>”. What I never hear is: “We need to bring our development and testing methodologies up to date”, “We need more collaboration across our teams”, “We need to inventory our skills and see what’s missing”.

If we think of the IT organization as a basketball team, that would be the equivalent of the coach saying: “We need more 3-pointers”, and “We need those fancy new shoes to be able to dunk”.  Whereas even the most inexperienced youth coach knows that the key to winning includes: “We need to practice dribbling and footwork”, “We need to communicate better on the court”, and “We need to improve our free throws/jump shots/rebounds”.

While it is both valid and necessary for IT organizations to push towards the big picture objectives highlighted by glossy Gartner and Forrester whitepapers, these have to be supported by continuous and deliberate investment in foundational concepts.

Let me step in as coach for a moment and propose a strategy for focusing on the foundation…

1)    Invest in the basics: Invest in good basic IT delivery concepts, kind of like dribbling, footwork, and basic fitness in basketball:

  • Make Business Analysis about teasing out the requirements from the Business’ objectives, rather than simply asking the Business to write down their requirements
  • Encourage good testing rigor and embed it throughout the entire solution delivery lifecycle, and not just at the end just before go-live
  • Promote good documentation habits and create templates for common documents (e.g., logical solution architecture, functional designs, interface specifications, data models)
  • Spend adequate time and budget to implement solutions which improve developer productivity (e.g., continuous integration, 3rd party frameworks)
  • Allocate budget for developers to learn different languages so they can be exposed to different software concepts and improve their coding skills
  • Spend generously on training for system analysis, modeling, design methodologies (e.g., domain driven design, SOA, microservices architecture, semantic modeling, BPMN), and not only on those being standardized by the organization, but to improve people’s ability to make smart decisions

2)    Communication is key: Create an environment that promotes collaboration and teamwork:

  • Create communities of practice across your organization (or connect to external groups) to build on collective knowledge and experience
  • Implement real-time collaboration tools (no, Sharepoint and instant messenger don’t count)
  • Make governance less about formal approvals and more about ensuring the right expertise is pulled in at the right stage of a given project
  • Adopt iterative delivery methods to promote frequent touch points between IT and Business obtaining feedback and ensuring alignment

3)    Focus on the right skills: Build the skills that support your strategic objectives. After all, dunking is only made possible by training to jump higher:

  • Strengthen Information and Data Management capabilities as a foundation for Big Data Analytics
  • Educate the team on hashing algorithms, binary trees, digital contracts, and distributed storage to bring Blockchain to the table naturally
  • Leveraging Cloud means good distributed system design, loosely coupled interfaces, container-ready applications, and security frameworks that can deal with 3rd party infrastructure
  • Adopting COTS requires strong technical Business Analysis, ability to negotiate requirements with the Business, and strong platform administration skills

We all want to work with the cool new tech and follow the latest trends. Working with the latest and greatest is what draws people to technology work. But the team will be stronger if the foundation is strong and the team is well connected so take time to build our own skills and our teams’ foundations so we can all up our game.

  • Shan
  • Gu

Introducing the Orbital Bus

Today, we are proud to announce the public beta launch of the Orbital Bus open source project. The Orbital Bus is a distributed Enterprise Service Bus (ESB) intended to make it easier for developers to implement smart, reusable, loosely coupled services. We believe that a peer-to-peer mesh of lightweight integration nodes provide a much more robust and flexible ESB architecture than the traditional hub/spoke approach. Please check out our public repository and documentation.

I have been working in Service-Oriented Architecture (SOA) and with Enterprise Service Bus (ESB’s) for the majority of my career. I can’t even count how many debates I’ve been in on the value of implementing an ESB and how a hub/spoke architecture is more sustainable than point-to-point integrations. In fact, for a number of years, I took the architectural benefits of an ESB for granted.

By 2013, I was starting to see a pattern of large enterprise clients struggling to adopt SOA not for architectural or technology reasons, but for organizational and cultural reasons. I came to the realization that while ESB’s were being sold as bringing about a certain type of architectural rigor, it could only do that if the organization was very hierarchical and centralized. The ESB is really not well suited for an IT organization made up of more distributed teams and governance structures.

We thought of a better way to solve the real-time integration problem. With the help of some funding from NRC’s IRAP program, we started development of the Orbital Bus in 2015. The goal was to solve some of the major shortcomings that we see in traditional ESB’s:

Single Point of Failure – An ESB creates a single point of failure, as all common integrations must pass through it. Enterprises spend a significant amount of money to improve the availability of their ESB infrastructures (e.g., hardware redundancy, DR sites, clustering). What if the responsibility of translation and routing was pushed out to the edges to where the service providers are hosted? There would be no point of failure in the middle. The availability of each service would purely be dictated by the service provider and the lightweight integration node sitting in front of it, which means one node going down wouldn’t impact the rest of the ecosystem.

Implementation Timelines and Cost – ESB’s take a long time and a lot of money to stand up. A lot of effort is needed to design the architecture so it’s future proof and robust enough for the entire enterprise. And then there’s the cost of the infrastructure, software licenses, and redundancy. Never mind the cost of bringing in external expertise on whichever platform is being implemented. What if the platform actually promoted more organic growth? Each node is lightweight and could be stood up with no additional network zone or infrastructure. Developers will be able to build decoupled interfaces between handful of systems in a matter of days rather than months. And instead of needing to fiddle with complex platform configurations and go through 200+ page installation guides, the ESB could be stood up with a handful of scripts and created native service bindings in commodity languages such as C#.

Developer Empowerment – ESB’s move the responsibility of creating decoupled interfaces from the developer of the service into a central ESB team. It’s no surprise that nearly every SOA program I’ve ever worked on faced significant resistance from the development teams. And let’s face it, most IT organizations are poorly equipped to handle major culture changes, and that resistance often results in the killing of a SOA program. What if the architecture actually empowered developers to build better and more abstracted interfaces rather than try to wrestle control away from them? The platform would promote a contract-first implementation approach and generate all the boring binding and serialization code so developers can focus on the more fun stuff. By having the service interface code artifacts tied more closely to the service provider code, it opens up opportunities to better manage versions and dependencies through source control and CI.

We’ve had a lot of fun designing and developing this product over the last two and a half years. We are excited to offer the Orbital Bus to the community to collaborate and gather as much feedback as we can. Working with the open source community, we hope to create a more efficient and developer-centric way of integrating across distributed systems. We hope you will join us on this journey!

  • Shan
  • Gu

Embracing the Technology Meltingpot

One of the most common objections I hear among my large enterprise and government clients when discussing adopting new technologies is “We’re a Microsoft shop so why would we look at a Java-based tool?” or open source, or Google, or Salesforce, and the list goes on.  This objection is grounded in the opinion that increasing the technology mix increases complexity, and thus increases the operational risk and cost.

However, the biggest challenge for IT executives has shifted from tightening their operational budgets to managing the constant risk of technologies becoming unsupported or having a vendor development path that no longer aligns with the enterprise’s needs.  The technology market is evolving and changing faster than ever.  Programming languages grow and wane in popularity and support over a cycle of just a couple of years; new frameworks breath new life into technologies that were previously left to die; acquisitions can make entire enterprise platforms obsolete overnight; and new innovations are happening constantly throughout the IT stack from networking, to virtualization, to application platforms, to business applications.

In such a rapidly changing and unpredictable environment, the best approach to managing risk (as any good investment adviser will tell you) wordleis to diversify.

In fact, any IT organization that doesn’t have an openness to innovate and investigate new technologies will ultimate die a slow death through obsolescence and operational bloat.

Instead of being afraid of the operational complexity and cost introduced by shaking up the technology stack, IT executives should be embracing them as opportunities for their teams to develop new skills and to gain a wider perspective on how to implement solutions.  Instead of remaining within the comfortable confines and protections of a given development framework, developers should be pushed to understand how different technologies interoperate and the importance of having disciplined SDLC methodologies to deal with complex deployments.

The key to success in all of this is integration.  Developing mature integration practices like modular design, loose coupling, and standards-based interoperability ensures that new technologies can be plugged into and unplugged from the enterprise without cascading impacts on existing systems.  Disciplined SDLC methodology especially around configuration management and change control allow different technology teams to work in parallel, resulting in more efficient project delivery.

IT organizations must adopt a culture of openness and curiosity to from the inevitable changes to their technology ecosystem.  They must invest in mature and disciplined integration practices to effectively manage those changes.

  • Shan
  • Gu

Prescriptive Governance Leads to Shadow IT

Let’s face it, to most people in IT, “Governance” is a dirty word.  That perception is not born out of an idea that IT governance is bad, but out of the reality that IT governance is badly implemented in most organizations.  When an organization confuses good IT governance with overly detailed and prescriptive IT governance, it starts to constrain rather than enable its people.  And when people feel constrained and not empowered to make the decisions, they work around or against the process, which then results in proliferation of shadow IT.Governance_ShadowIT

The reason for this phenomenon is that many organizations approach IT governance with a few very flawed assumptions around how software and technology projects work:

  1. Changes are bad;
  2. Consistent results are driven from consistent processes;
  3. Standardization reduces the number of decisions, which makes the process more efficient and consistent; and
  4. Measure of a good project is on-budget and on-time.
These assumptions are fatal to any IT organization because they fail to recognize the realities of the nature of technology and the people implementing it:
  1. Technology is about change.  The whole point of implementing technology is to support and enable more rapidly changing business needs.  Add that to the speed of technology changes, the default position of any good IT governance process should be to assume constant change and deal with it head on instead of trying to contain and avoid it.
  2. Speaking of change, there is no way for a one-size-fits-all process to anticipate all the different ways a technology project can unfold.  In fact, the more prescriptive a process is, the less likely it will fit the next project.  There are simply too many variables and moving targets in modern enterprise IT projects.
  3. You hired smart people to implement technology and guess what?  Smart people like to make decisions and feel ownership of their work.  By over-standardizing, talented tech resources are turned into the IT equivalent of assembly line workers.  At best they become disengaged and stale in their skills.  But more likely, they take matters into their own hands and create opportunities to make decisions or fight the governance process to retain some ownership of the work they’re being asked to do.
  4. IT initiatives exist to make your business better and the users happier.  While budget, scope, and schedule are important, they’re management measures on the process rather than whether a project was truly successful.
So how do we fix this?  In a word, simplify!  And here are some things to think about when slimming down your IT governance process:
  1. Reduce and align the number of gates to the number of “point-of-no-return” decisions on a project (e.g., business case, functional design, technical design, go-live).
  2. For each gate, focus on what kinds of decisions need to be made, guidance on people who should be involved, and some basic examples of information that should be provided as input.  Let the smart people do what they’re being paid to do, which is talk it out and own the decision.
  3. Standardize only the mundane and highly repeatable decisions.  Standards are about helping speed up the process and focusing the effort of only debating things that deserve to be debated.  It’s not about compliance metrics and enforcement.  If you have to put in an exception or exemption process, you’ve gone too far.
  4. Ensure communications on what the project will deliver in terms of functionality and value.  Most stakeholders care a lot more about whether a particular feature set is being implemented for their users rather than whether a particular deliverable is green or yellow.
In the end, this is about creating a process that helps to focus people on the real objectives of the business and fostering communications.  It’s about assuming that people are intelligent and reasonable and capable of making good decisions when given the opportunity.  And if that turns out not to be the case, it’s a HR problem and not something that should be fixed with yet more governance processes.
  • Shan
  • Gu

The Quiet Evolution of SOA

We’ve all found ourselves looking at an organization’s web services and commenting on how “It’s not really SOA”. Maybe because the program still maintains point-to-point interfaces, or maybe the organization hasn’t put in place any form of governance, but for whatever reason, we declare that it simply isn’t comprehensive enough to be considered SOA. That begs the question then: who is actually doing TRUE enterprise wide SOA? Well… very few organizations. Anne Manes famously declared that “SOA is dead” back in 2009. So why is it that we still find ourselves evangelizing and building towards this vision?

The answer is that our understanding of what makes an SOA program successful has quietly evolved over the last few years. Enterprise-wide re-platforming and re-architecture initiatives gave way to tactical adoption of SOA. The success of SaaS and BPM adoption meant that organizations are implementing the principles of service orientation without explicitly calling it an SOA program. And instead of trying to figure out just how to effectively measure SOA ROI at the enterprise level, much greater success has been found measuring the value created within a given portfolio and/or capability.

So while we Architects have not given up on the hope of achieving SOA utopia, we have become more realistic in our approach:

  1. Identify a very specific problem to solve with an SOA approach, be it to reduce the time-to-market of a frequently changing business process, or to reduce the application footprint of a given line-of-business.
  2. Demonstrate the value of SOA by successfully solving that problem.
  3. Rinse and repeat.

At the end of the day, any plans for enterprise level SOA can only be built a critical mass of successful self-sustaining SOA capabilities/portfolios.

  • Shan
  • Gu