Startups and Social Capital

At a recent evening meeting, a panel discussion under the #thinkleader program sponsored by IBM, the panelists represented different startups. They were smart, energetic and focused, aware of the murky waters in which they swam. It was clear that they had considered and planned for financial capital; likewise for the talents and skills needed. But a common thread of difficulties had to do with external support for their fledgling companies.

One panelist had been surprised at the drop-off from when he was a manager at a well-known brand, with many eager acquaintances, to the sudden vacuum now that he was co-founder of a startup. It wasn’t just the challenge itself posed by the need for external support, those willing to give referrals on their behalf, pass along useful ideas and the like, but the element of surprise of that drop-off.

Startups need to include building of social capital as part of their business plan. It’s not just marketing or branding. The ability to count on someone for information, for referrals, for the myriad types of support that can face a startup is a form of wealth. In a prior post, focused on individuals, the concept of Cognitive Wealth was explored. Similarly for startups, social capital needs to be planned for and built, as an explicit part of the business plan.

And if you’re young in your career or going through a major change, try thinking of yourself as a startup.

Advertisements

Innovation and the Octopus

To create something innovative, one needs to look at things in a new way, going a quantum leap away from the well-trodden paths of the usual. To help stimulate creativity, try examining something unusual, something very different from our familiar world view.

Our way of viewing the world is that of an upright two legged, with two upper limbs and a hand at the end of each, having prehensile fingers.

Our companion animals usually are 4-legged, mostly with more acute sensory abilities than us, but overall, not too unlike ourselves and our view.

Our robotic creations tend to follow those structures and patterns, remaining close to the familiar.
For a very different perspective, consider the octopus and their marvelous abilities; a species millions of years older than our own.

Invertebrate: a large octopus can still squeeze through a 2 inch opening (or even smaller), presenting a challenge to keeping curious octopuses inside man-made containers or tanks. To date our robotic designs are vertebrate-centric; one might consider a soft robot, modeled after the octopus.

While almost all our cognitive neural capacity is centrally located in our brain, the octopus uses a more distributed model, with only about half centrally located, with the rest distributed to its limbs.

A user of tools and toys, one might contemplate what an octopus considers amusing or beautiful. What are the means and media of beauty and harmony for an octopus? How might that intersect with our own aesthetic concepts? Does the geometric pleasure of a Bach fugue resonate for an octopus?

Octopuses exhibit a wide range of behavioral patterns, perhaps falling into categories: are some more extroverted? How can one design a Meyers-Briggs type personality test for an octopus? For robots, how does one differentiate an introvert versus extrovert?

One might not readily associate the octopus with fashion and design, but some creative ideas might arise from contemplation of how a color-blind creature superbly camouflages more quickly than a chameleon. Could a chair be adaptive to the color or pattern of clothes worn by the person adorning it? Or have jewels adapt to nearby attire? (e.g., a modernized, Tiffany-class mood ring).

So much difference from our own way of being, our perceptions, should lead to some inspirations for innovation.

For those curious about the wonders of the octopus, try Sy Montgomery’s “Soul of an Octopus”. It’s a rich, clear and easy read, with the author’s tinge of wonder about the world.

Increasing Cognitive Wealth

Your cognitive wealth is the sum of what you know, your personal knowledge, that which you are able to perceive; plus knowledge readily accessible whether from a search engine on the internet or from one’s personal library; plus information easily obtained from others.

The part based on one’s personal knowledge is the easiest to control and have immediate impact. Develop an approach to learning; think about the processes you perform when trying to learn something new. Your strategy for learning should include some way of becoming aware of new things that might be of interest, continuing to broaden your horizons. For me, reading is a preferred way of increasing my personal knowledge, supplemented with online video tutorials, and face-to-face group meetings, especially for subjects of professional interest.

The part that is readily accessible knowledge is a bit trickier. One is now relying upon tools (a book is a tool). One of the challenges is to find the right tool at the right time; a large personal library without some organization is of diminished value.

To increase the wealth brought by the internet, learn about the parameters of search engines. One needs to supplement the general search with a more focused one. Valuable nuggets are often buried far down when using a general search. For example, use of the “site:” modifier might yield information closer to the top of your search list. Another is to try other search engines, perhaps specialized ones.

For some topics augment your search engine by directly searching in Twitter. The jewels there might take the form of links to useful articles that might not show near the top of results from a general search engine.

Enriching the quality of one’s relationships with others increases the ease of obtaining information from them. You need to be aware of not just who might have knowledge on a topic, but also of their willingness to share with you, and the ease you have in communicating your need to them.

One means of improving that is to make your own knowledge readily available to others. Carrying this further, if I know someone well enough, I’ll keep my eyes open for information of likely interest to them. A form of social arbitrage, not only connecting people with others, but with information that they’d appreciate. That connecting and sharing enriches not only you, but those around you.

Agile User Stories and Application as Persona


In Agile, requirements are communicated via user stories.  Traditional user stories use the form, “As a …, I want to …, so that I can ….”.  For example, “As a first time user, I want to be able to create a user name and password, so I can securely do transactions.”   That enables functional requirements to be captured as user features, but still does not address the often critical “non functional requirements” (NFR) in an Agile framework.  NFR are items sometimes associated with infrastructure, such as capacity, scalability, reliability, availability, or security.

One approach to including NFR in an Agile context is to create user stories based upon the application itself as having a role or persona.  For example:

“As an application, I want to be able to process xxx transactions per second, to be able to handle peak monthly demand.”

“As an application, I want to be resistant to SQL injection attacks, so that my transaction integrity remains valid.”

Appropriate acceptance criteria need to be included; phrasing those can be challenging in these cases.

Extending the concept of the application persona further, it can also be used for other aspects of the application, such as user interface or user experience.  Those may fall outside the straightforward transactional features covered by more typical user stories; use it for the more qualitative ones, the fuzzier parts.  The usual guidelines still apply: make the story as granular as possible;  and to include acceptance criteria.  Acceptance criteria can be very difficult to create when one is trying to specify aspects of user experience as quality or beauty.

Taking this further still to the more general case of product development, including the difficult cases of ad campaigns or branding, the concept of the application or product as a persona remains tenable.

E.g., “As a brand, I want to be able to highlight the excitement of using our products, so that I can …..”

What’s Missing From Your SDLC

Having an SDLC (Software Development Life Cycle) documented is not to provide a minimum effort on development, or something to ignore, and keep writing programs as the mood strikes.  It’s part of an effort to follow best practices, to deliver high quality software on a repeated basis.  Even Agile methodologies can have an SDLC.

SDLC’s usually cover the core of the process of software creation, from initial requirements through design, coding, testing, integration, user acceptance, etc.  Some key elements are often overlooked, or considered not to be part of software development.  I’d like to suggest that you think about some areas that might improve the quality of the software you create if they are part of the SDLC.

Production support is not just about maintenance and fixing defects.  It’s about the ongoing improvement of what you delivered, preparation for the next release; part of the SDLC.  It’s about empowering the users, giving them the ability to fix their own problems when possible and reasonable; giving the right tools to the first level of support.  Not just documentation, an FAQ, or online Help, but items like creation of an error log and error trapping.  If the application has a database or data store, did you design a quality check on stored data, not just relying upon front end edit checking?

Does the application offer its users the opportunity to report problems, or give feedback about the interface they use?  What are the processes you envision for the ongoing improvement of the product?

Some SDLC’s include a Lessons Learned as part of closing out the development effort, project wrap-up.  The problem with that is it doesn’t do any good for the project in question, since that’s over, and seldom is examined either for the next release or by other projects.  Taking a page from the Agile approach of a retrospective for each iteration (sprint), why not do a Lessons Learned at each major milestone in the project, so the project can actually benefit while still in progress.

Security reviews should be part of the SDLC for all applications, not just web apps, not just for external facing ones.  How vulnerable is your application if another behind the firewall is compromised?  Security is part of the design process, not just something during the testing phase.

Security challenges are constantly changing, and some level of awareness needs to be part of the mindset of developers, not just IT security professionals.  Look towards organizations like OWASP (Open Web Application Security Project) as a resource.  Their Top Ten Security Risk list might startle some of your peers.

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

The Department of Homeland Security has some excellent resources, such as a National Vulnerability Database http://nvd.nist.gov/  as well as checklists and guidelines.  Look around their site.

Security is often a nightmare for developers, but there are people, organizations and tools to help you.

Look at your SDLC, think of the ongoing life of your applications, and what might enhance their quality.  The SDLC is an ongoing opportunity for process improvement.

 

Rejuvenating the Infrastructure

The lack of agility of the infrastructure, especially the data center and systems programming/ administration is so obvious that the nascent DevOps movement has arisen to combat this perceived deficiency.  Much of that movement’s visible contribution has focused on automation and tools (e.g., Chef, Puppet, cfengine, Nagios) rather than on frameworks or processes.  Not surprising, given the talent for coding of many of the DevOps advocates.

There are other obstacles:

The Data Center values stability of the environment, and resists change; change is seen as a risk, not as any form of added value.  In general, perhaps especially for larger IT shops, other than changes due to bug fixes or security patches, the data center is isolated from positive aspects of application and environmental changes.  New metrics could provide a more flexible approach along the lines of increased Business Value (BV).  Some places, especially those along ITIL lines, may use a metric for risk as part of Change Control, but I have not heard of a corresponding one for enhanced BV.  That BV metric could be a 1 to 5 scale, or a set of numeric guidelines.

Much of the effort of the infrastructure is about process, with solutions well defined.  The challenges are more along the lines of:

–       Sheer scope of tasks, as the whole enterprise may be involved, with associated risk of that dimension.

–       Interdependencies

–       Complexity

–       Volume of work (especially with sharp peaks)

–       Lack of teams

For volume, automation and tools can help; one should also investigate frameworks like  Kanban, limiting the work in progress at any moment.

The lack of teams in infrastructure remains a source of concern for me.  Teams, behaving as teams, not just silos of individuals with common product-oriented expertise.  For example, a group of system administrators each with distinct separate sets of servers to manage, with no or little collaboration between members of the group, is not a team. The situation not only deprives the company and the participants of the benefits of a team approach, but reinforces the sense of isolation and endless repetition of upgrades and patches.

In my prior blog post on Skill-Centric Teams, a key point is that teams can be created across functional silos, basing them on the shared skills and challenges.  While there are distinct differences between a UNIX system administrator, the Windows counterpart, and their mainframe brethren, but there is so much in common, including, but not limited to:

–       Issues of change management

–       Communication with developers

–       Application development (AD) support methodologies or frameworks

Application development infrastructure support frameworks deserve a separate post.

 

Database Vulnerabilities and NoSQL

Information Security professionals state that perimeter security alone is not sufficient; just having network firewalls is not enough to secure your environment.  Both devices and people can circumvent perimeter security.  Devices:  how would you discover if a wireless router was placed on your network?  People:  do you ever use consultants, temps or contract workers?

There are many ways DB’s are vulnerable, with new ones occurring with new features and new releases.  How current is your DB on security patches? Did any of your DB installs create demo or sample databases?  While those don’t have sensitive data, they do represent security exposures.

At a recent chapter meeting of a web application security group, OWASP, some vendors were present.  Chatting with one, Application Security (http://appsecinc.com ), I was glad to learn about a tool that deals with database vulnerabilities, DbProtect.  I’m sure it has competitors with similar functions, but to me, not an InfoSec specialist, it was very impressive, covering most of the common distributed DB’s.

While the mainstream relational DB’s have tools to help address vulnerabilities, the newer NoSQL data solutions do not, yet are subject to many of the same types of vulnerabilities.  Use of MongoDB, CouchDB, Riak, Redis, Hadoop, MapReduce, etc. continues to rapidly grow.  And these are being used in more business-critical applications, or with sensitive data.

Even if used for non-critical applications and non-sensitive data, they still can present a risk, for some may have accounts with privileged access to the critical DB’s, the relational ones; or they may provide elevated access to the operating system.

If you’re using a NoSQL DB, check with your vendor for security assurance tools, or at least some recommendations for those.  Make inquiries of existing DB security vendors;  even if they don’t currently have a suitable tool, they might respond to market demands and create one.

Even if insufficient when compared to commercial products, in the absence of a suitable tool, consider creating a tool, script or checklist to seek common vulnerabilities. Change passwords to any DB default accounts, and use strong passwords (not ones that might appear in a dictionary.) Check for vendor patches frequently.  Keep posted about security exploits against that specific DB.  Something like a Google Alert using a string based upon the DB name (e.g. Sybase) and “security exploit” could bea s good starting point.  Keep learning about DB security.