Random Acts of Architecture

Tales of an architect trying to bring order to the chaos that is modern information technology.

Tag Archives: Perspective

InfoSec: Not just for hackers

everybody-needs-a-hackerI recently read Troy Hunt’s blog post on careers in information security. Troy makes good points about information security as a potential career and the benefits of certifications like the Certified Ethical Hacker. Hackers are getting increasingly sophisticated, requiring specific knowledge to counter, and cryptography is hard. We need more information security specialists.

However, one criticism of the post, indeed the information security industry, is its implication hacking is the sole information security career path. This binary viewpoint – you are either a security person or not and there is only one “true” information security professional – does more harm than good.

Hacking is technology focused. However, security’s scope is not just technical. Information security needs people that can articulate security issue impact, potential solutions and their cost in terms non-security people can understand. This requires expertise and credibility in multiple disciplines from individual contributor level to management to boardrooms.

Security solutions are not just technical. We live in societies governed by laws. These can be standardized government security requirements as FedRAMP or IRAP. These can be contractual obligations like PCI-DSS, covering credit card transactions. These can hold organizations accountable, like mandatory breach disclosure legislation, or protect or privacy, like the European Union’s Data Protection laws. Effective legislation requires knowledge of both law and information security and the political nous to get it enacted.

We are also surrounded by financial systems. Financial systems to punish those with weak security and reward those with good security will only evolve if we (consumers and investors) value security more. Cyber insurance has potential. Cryptographic technologies like bitcoin and block chain algorithms are threatening to disrupt the financial sectors. Information security has and will continue to impact finance.

The list goes on. Law enforcement needs to identify, store and present cybercrime evidence to juries and prosecute under new and changing laws. Hospitals and doctors want to take advantage of electronic health records..

The security technology focus drives people away non-technology people. In a world crying out for diversity and collaboration, the last thing information security needs is people focusing solely inward on their own craft, reinforcing stereotypes of shady basement dwellers, and not on systems security enables.

Bringing this back to software, many organizations contract or hire in information security experts. Unfortunately, the OWASP Top 10 changed little from 2010 to 2013 and some say is unlikely to change in the 2016 call for data. According to the Microsoft Security Intelligence Report, around half of serious, industry wide problems are from applications. Developers make the same mistakes again and again.

Education is one solution – security literate developers will avoid or fix security issues themselves. A better solution is tools and libraries that are not vulnerable in the first place, moving security from being reactive to proactive. For example, using an Object-Relational Mapping library or parameterized queries instead of string substitution for writing SQL.

Unfortunately, security people often lack skills to contribute to development and design beyond security. While information security touches many areas, information security expertise is not development (or networking or architecture or DevOps) expertise.

Information security needs different perspectives to succeed. As Corey House, a Puralsight author like Troy Hunt says in his course Becoming an Outlier, one route to career success is specialization. Information security is a specialization for everyone to consider, not just hackers.

Image credit: https://www.flickr.com/photos/adulau/8442476626

The Future of Product Management in Enterprise Software

PM Challenges

In traditional enterprise software, product managers represent the customer to software development teams. They draw on industry experience to propose and prioritize features, usually as the scrum product owner. They liaise between development and the rest of the business, particularly marketing and sales.

However the product management role has three main challenges. The first challenge is new business models, particularly the move from on premise software to the cloud.

Cloud software presents increased non-functional challenges. For example, cloud systems are expected to scale up further than on premise software. The burden of service level agreements (SLAs), upgrades, patching and backup/restore is on the vendor and not the customer. Cloud systems are usually Internet accessible, missing the protection of an organization’s perimeter security measures like firewalls. Multi-tenant systems and resource pooling mean quality issues and downtime can affect many or all customers and not one.

Where product management previously dictated product direction, product management now share responsibility with architects (enterprise, solution, infrastructure and application) and business analysts (responsible for internal business processes). While IT commoditization has made IT cheaper and more accessible, capable technical people are still required, albeit with a different skill set. The increasing emphasis on integration, such as exposing web service APIs to third parties, and multiple platforms, such as mobile and tablet, exacerbates this.

However, this gives a product manager more opportunities. With the move from capital expenditure (initial purchase + support) to operational expenditure (monthly charge), many organizations are liberated from a fixed purchasing cycle. Unburdened by the three to six month customer upgrade period, releases can be as frequent as the development team can accommodate. Product managers can offload technical problems rather than shoulder the responsibility of the whole product.

The second challenge confronting product management is the increasing use of analytics and metrics. Many industries, such as media, have been using analytics and metrics for some time but many traditional enterprise market segments are only now getting access to accurate usage information. For example, few organizations previously consented to on premise products sending usage data back to the vendor.

Many product managers rely on experience or recent customer conversations to make decisions. However, the on-demand provisioning, self-service and customer customization (as opposed to vendor customization) aspects of cloud products reduce customer contact. Analytics and metrics can help fill this gap but it is a different type of customer relationship.

Moreover, the quality and quantity of decision-impacting data is increasing. Tools and expertise to extract useful information are becoming cheaper and more prevalent. Intuition and experience are always useful but will be more focused to what metrics to gather and interpreting them. Decisions will have a grounding (or at least a rationalization) in data. Making a decision solely on a “gut feeling” will be less acceptable.

Also note that good analytics and metrics can easily be applied to tactical problems like improving a user interface or prioritizing between two features based on actual use. It is harder to apply analytics and metrics to strategic questions like market direction or new product acceptance. This is where product management insight will be most valuable.

Metrics also help mitigate the “squeaky wheel” effect, where vocal customers monopolize product management time and the product backlog. For example, it is easier for a product manager to dissuade a customer demanding improvements to a certain feature with evidence the feature is rarely used.

The third challenge is the rapid change. Many product managers come from a business role. For example, an HR application product manager may previously been a manager in HR. Others have come from customer-facing technical roles like support, QA or sales engineering.

Unfortunately, in some industries previous industry experience is quickly outdated. While product management’s customer-focused perspective is vital, being removed from the industry can quickly atrophy understanding of customer processes and priorities. Exposure to their own software product(s) and current organization threatens to limit their thinking to what is probable, not what is ideal.

This is particularly important for product managers that come from customer-facing technical roles. They usually come to product management with specific product improvements in mind but, once these are in the product, may be at a loss.

Instead, a product manager needs to build ways to learn and predict industry changes – developing a new feature often takes months and the feature must be competitive when it is released, not just today. This could be key customers, industry contacts, thought leaders, peers at competitors or industry press. Building personal relationships, such as at conferences and industry meet-ups, is crucial.

Moreover, many information sources available to product management, like metrics or competitor analysis, are available to others in the software development team. It is these alternate information sources and relationships that will differentiate a good product manager.

Product management can no longer horde this information. For example, architects need accurate customer usage predictions for scalability planning and infrastructure provisioning. Management needs to allocate staff. Operations needs to ensure they are looking for likely threats or issues. By the time these are included in a release’s requirements or a sale occurs, it may be too late. Hording assumes product managers are the only ones making strategic decisions. Product managers are often poor conduits for technical requirements, too.

Meanwhile, product managers have less available time. They are dragged into sales opportunities to demonstrate or demand commitment, support calls to placate unhappy customers and marketing for feature commitments. Agile software development methodologies, like scrum, involve the product manager more frequently. This creates a “red queen” effect, where product managers spend a lot of their energy merely keeping pace with the industry, competition and own products.

Product management has always been a challenging role – often all responsibility and no authority. While many technical people incorrectly equate product knowledge with industry knowledge, prior experience and a customer perspective are no longer sufficient to be a good product manager. Successful product managers will adapt to the new business models (e.g. cloud) and leverage the new tools (e.g. analytics and metrics) to be more effective. In the future, those that rely on outdated experience and intuition are likely to fail while those that learn and adapt quickly will succeed.

Indeed, the end goal of product management is to impart customer perspective and industry knowledge. There will always be a place for a coordinating customer voice but it will lead by teaching, not a requirements document. Those involved in development should not need to consult product managers for every new feature or for a customer perspective – product management should have already taught them to think like a customer.

Developer to Architect: A Matter of Perspective

When interviewed for a promotion some time ago, the interviewer told me two developers are arguing over whether to use programming language A or B for a project and asked me which I would recommend.

There are different ways to answer the question. The first is technical, comparing the language minutiae, libraries, IDEs and tool support. It argues the merits of the vendors, communities behind the languages and often has a bias toward favourite languages or tools.

Team leaders and managers approach the problem differently. They look at the existing skills of the team. They look at support structures (such as contracts and consultants), the longer term viability of languages and their organization’s investments in each. They consider the risks and benefits.

I gave both these answers. While correct, these answers miss a critical viewpoint: customer benefit. For example, the product may have to integrate with existing applications using mechanisms only supported by or heavily geared toward certain languages, like COM with C++, Visual Basic or C#. The target device or operating system may support one primary language, such as iOS and Objective-C. Languages may have runtimes that require additional configuration and patching, such as Java or Flash, and the customer lacks the infrastructure and expertise.

Customer benefit is an assumption so implicit in the question that people consider it assumed or ignore it. However, this assumption is what makes the question a great (trick) question, particularly for a software architect that needs to interpret, challenge and identify requirements.

“We do not see things as they are. We see them as we are.” Talmud

Moving from a developer to an architect involves a change in perspective. Developers leap to details with the “how”, arguing libraries or techniques. Managers identify resource requirements and risk. Architects step back and ask “Is this even the right question?”

“Nothing is more dangerous than an idea if it’s the only one you have.” Emil-Auguste Chartier

Thinking inside the box is easy. Thinking outside the box is hard. Finding the box is harder still. Architects may specialize but are expected to delve into enough detail to validate a proposed solution without risking leaping to conclusions or becoming too attached to a solution. Developers focus on the best and fastest way to solve a given problem.

“The limits of my language is the limit of my world” Ludwig Wittgenstein.

Design patterns are useful for conceptualizing and communicating designs. Understanding the business problem and customer viewpoint is critical to identifying the best solutions. Architects straddle both the developer and customer worlds and so must learn the terminology of both and translate concepts between them.

“It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” Lewis Carroll

It is an understatement to say technology changes rapidly. Whereas developers must keep up with their chosen tools and languages in detail, architects evaluate and adapt to a wider set of technologies but less deeply than a developer, particularly those architects responsible for a technical strategy or vision.

“It is a painful thing to look at your own trouble and know that you yourself and no one else has made it.” Sophocles

Architects are responsible for the product without being the ones implementing it, including design delegated to others and trade-offs  made to handle  technical or business constraints, and their role is as much communication and evangelism as high level design. Managers have long been accustomed to this level of responsibility and facilitation but it may be new to a developer.

Of course, this is not to say a developer cannot think like an architect or manager (or other permutations) or that these are immutable, defined roles. Like Edward de Bono’s Six Hats, recognizing that there are different viewpoints and switching between them is key. It is also challenging, particularly when under the pressures of commercial software development. Or an interview.

%d bloggers like this: