2100 Solutions – NEW Ruby on Rails website NOW in production on Heroku

After a few embarassing announcements, and failed launches, I have successfully re-crafted my website2100solutionsLogofor 2100 Solutions Consulting, LLC.   This branding of my services includes, Program Management, BPM Strategy, Quality Assurance, Testing, Performance Preparation and Strategy, Automated Testing and Product Development.

Here is a URL for the Ruby on Rails website I just launched using the Heroku enviornment this weekend.  http://2100solutions.com

Heroku was by far the easiest host to implement.

Now a stable 24/7 presence with links to my external blogs and pursuits.

I have other RoR websites completed, but not yet launched on Heroku.   All published websites will be managed through GitHub.  My account at GitHub is WAFulbright, if you’d like to see or follow or contribute to my code!  Let’s do talk before you contribute!   Thanks!

Bill Fulbright

 

Advertisements

TEN REASONS WHY PEOPLE LOSE THEIR JOBS

TEN REASONS WHY PEOPLE LOSE THEIR JOBS

So many of these people who lost their jobs are the victims of a poor economy or a struggling company or both. They are capable and hardworking, and their unemployment is not due to their lack of effort or desire.

Some people, however, lose their jobs due to factors they could control. I recently polled a number of leaders and asked them to tell me the top reason or reasons people lost jobs in their organizations. I asked them not to include those whose jobs were eliminated due to economic or financial reasons of the company. I was able to group their responses into ten categories. Although my poll is not scientifically validated, I think it is nevertheless instructive. Below are ten responses, listed in order of frequency, and realizing that there is some overlap in the categories.

  1. Failure to keep current in their field. “Rapid change” has almost become cliché. One leader said he had to dismiss some people who were acting like it was still 2007. In other words, if you haven’t kept current or updated your skill set in the past five years, you are incredibly behind your coworkers. Other leaders said they expect their employees to reinvent themselves regularly.
  2. Poor relational skills. Those deficiencies include an inability to work well with others, poor self-awareness, and a self-centered attitude. I note the latter issue separately below because it was mentioned frequently. One leader told me that he let go of two of his smartest employees because their attitudes were toxic to the organization.
  3. Moral failure. I expected this response to be near the top and it was. Some of the most promising workers have been fired for actions that could only be described as stupid.
  4. Failure to carry out assignments. Some of the leaders expressed amazement at the number of people who failed to carry out an assignment and offered no explanation why they failed to do so. “One former leader on my team,” a CEO told me, “ignored my assignment for months without explanation. I guess he thought that the task would just go away.”
  5. Failure to take initiative. Some of those who responded to me were leaders in mid-size to large organizations. Their direct reports were brought into the organization with the expectation that they would be highly motivated workers. But when they failed to take initiative, their value to the organization diminished. “I need people who can come up with ideas and strategies on their own,” one leader said. “I don’t need to be giving them assignments with specific instructions every time.”
  6. Negative talk. Some people lost their jobs because they were the sources or carriers of rumors. Some were incessant complainers. And even others were simply negative people. Their dispositions and conversations made the workplace unpleasant and discouraging for others.
  7. Laziness. “Most lazy workers do not realize that everyone in the organization knows they are lazy,” a midlevel leader told me. “You can’t hide poor work hours and poor work ethic from others. I have to deal with lazy people in my division before that attitude permeates the entire division.”
  8. Attitude of entitlement. We did go through an era in America’s employment history where adequate work and sufficient tenure guaranteed some employees a lifetime job, benefits, and retirement. That era exists no more. Those who still have an attitude of entitlement may soon find themselves on the sidelines of employment.
  9. Failure to demonstrate productivity. Workers in organizations should regularly ask if they are being treated fairly for the work they do. If not, they should pursue other options. Workers can likewise be certain that now, more than ever, they are being evaluated in the same manner. Are they productive? Do they truly “earn their keep?”
  10. Self-centered attitude. More and more workers are evaluated by their attitude as well as their direct work. Are they team players? Or do they always and obviously act in their own self-interest? Do they demonstrate humility? Or do they demonstrate hubris?

The workplace is changing. In many ways, all of us are more free agents than career workers. We have to demonstrate our worth each day. Those who do so will have many options before them. But those who don’t may find themselves in the ranks of the unemployed.

What do you think of this list? What would you add, delete, or rank differently?

Key Needs for most Data Management Project

Thoughts and Key Strategies for Test Data Management:

Data Acquisition

  • Data Profiling and Distribution
    • Data that includes confidential or sensitive information can still be shared, however. There are a number of steps researchers can take to protect subjects’ privacy2:
      • withholding part of the data
      • statistically altering the data in ways that will not compromise secondary analyses
      • requiring engineers who seek data to commit to protect privacy and confidentiality
      • providing data access in a controlled site, sometimes referred to as a data enclave.
  • How is it provided
    • The data have its own device name and data name. The data is stored in a separate file with binary format. Each file has “n” number of columns for data, which generally represent various data features.
    • from stored historical data
    • Active systems / projects
      • from dynamic / fresh data
    • Web site/platforms
    • Mobile / OTA
  • Automated, Tool or Manual Data Preparation
    • Automated Accelerators
    • Tools such as Informatica, etc.
    • Manual teams – most used – and can be up to 40-50% of the project spend
    • defining test data
      • to be used in a test case,
      • copying or creating test data,
      • securing or masking sensitive data,
      • and so on—are taking up more than half a developers’ and QA team’s time during the testing phase.
  • Data Integrity
    • Data must be archived in a controlled, secure environment in a way that safeguards the primary data, observations, or recordings.
    • The archive must be accessible by engineers analyzing the data, and available to collaborators or others who have rights of access
    • Primary data should be stored securely for sufficient time following publication, analysis, or termination of the project.
    • The number of years that data should be retained varies from field to field and may depend on the nature of the data and the research.
    • Keeping data partitioned and limited to view by assigned groups
  • Data Maintenance and Refresh
    • When determining the appropriate storage format for  data, consider
      • What will you do with your data once you acquire it?
      • Will you write and read data with the same application?
      • How much data will you acquire?
      • At what rate will you acquire data?
      • Will you need to exchange data with another program?
      • Will you need to search your data files?
  • Data Governance
    • Rules and Policies for testing phases and teams
    • How is it used

Without Test Data Management

Define Test Data Requirements

  • Tester Efficiency
    • Cost Per Test Cycle = $2.7M
    • 100 Days, 300 Testers, $90/hour
    • 20% application defects due to bad test data
  • Application quality
    • Cost of a defect found later in the release cycle = XX

With TDM

Define Test Data Requirements

  • Improve Tester Efficiency by 30%                                         Improve Tester Efficiency by > 30%
    • Cost Per Test Cycle = $1.6M                                           Reduce Testing cycles by > 25%
    • 60 Days, 300 Testers, $90/hour                                       Improve application quality by 90% Tester Efficiency
    • 90% reduction in test data-related defects
    • Cost avoidance

ref: Informatica “Why Do You Need Test Data Management?” 
ref: Forrester Report:  “http://tealium.com/assets/pdf/Forrester_Boost_Digital_Intelligence.pdf

Discovery Analytics: It’s Not Hacking, It’s R & D, by Bill Franks

DiscoveryAnalytics

It’s Not Hacking, It’s R&D

Bill Franks has clarified the valued use of R & D as a reframe for pre-planning, analysis and pre-testing with this article. https://www.linkedin.com/pulse/discovery-analytics-its-hacking-rd-bill-franks

I spend a lotBillFranks of time these days talking with companies about the need for a formal approach to enabling what is often called “discovery analytics” or “exploratory analytics.” What I find is that many people have a fundamental misunderstanding of what discovery analytics is all about. There is one analogy that I have found to be effective in getting people to better understand the concept. In this blog, I’ll walk you through that analogy.

IT ISN’T AIMLESS HACKING!
Many people get very concerned when I begin to discuss discovery analytics as being not fully defined, constantly evolving, and remaining fluid. They tell me that what I’m saying sounds a lot like a mad scientist sitting down running random experiments in the hope of finding something useful. I do not espouse such an approach, I can assure you!
On the contrary, a discovery process should always start with a specific high priority business problem in mind. There should also be at least a general idea of how to address the problem effectively through analytics after some initial brainstorming. At that point, a discovery process is started to explore how well our ideas actually do address the problem. Typically, a discovery process involves one or more big unknowns:

  • We may be addressing a totally new business problem
  • We may be utilizing one or more new and /or largely untested data sources
  • We may be making use of analytics techniques that we haven’t used in the past

In short, while we think a proposed approach has merit, we really don’t know for sure how well it will work. The only way to find out is to dig in and see what we find. As a part of that process, we may well adjust our approach across any number of dimensions. The final solution we find may be somewhat different than the path we started down, but it will be found by remaining focused on the core problem we start with.

WE’RE REALLY TALKING ABOUT RESEARCH & DEVELOPMENT
If analytics is going to be a strategic component of your business, then you need to invest in analytics just like you do for other core products and services your company offers. Discovery analytics aren’t mindless hacking any more than traditional research and development activities are. People accept that an R&D team will have to be creative and try many paths to identify a winner. At first glance, some say that this is acceptable in a traditional product setting but not in a discovery analytics setting. I suggest that it is important to realize that the two are the same.
One of our high-tech customers takes only take a handful of new products to market in any given year. However, massive investments with many trial and error experiments happen behind the scenes to get those products ready. At the other end of the product complexity scale, quick-serve companies only bring a few new menu items to market each year. In their test kitchens, however, a never-ending stream of new recipes and ingredients are explored to arrive at the winners that make it to your local restaurant.

Discovery analytics are much the same. A variety of attempts will be made, of which only a few will turn out worthy of a full deployment. But, those that are worthy will have a high level of strategic value if efforts are focused in the correct areas of the business up front. Some ideas may not work out at all and will have to be abandoned. I’m sure there are also many computer chips or chicken sandwiches that never made it out of the R&D process either. Not every effort will turn into a winner, but working through the losers is the only way to get to the winners. In fact, if your analytics do not generate some losers, something is wrong: either they aren’t being made known, or the analytics team is not continuously pushing the limits of innovation.

RAMPING UP YOUR ANALYTICS R&D FUNCTION

It is critical to redirect discussion on discovery analytics toward the R&D parallel. People are much more comfortable with R&D because it is viewed as a rational, scientific, disciplined approach to developing new products and ideas. Discovery analytics is just that. Of course, it takes ongoing effort to ensure that any R&D function stays on the right path. With correct oversight and leadership, however, there is no reason your organization can’t reap large benefits from discovery analytics over time.

The best thing about building up an analytics R&D function is that it will self-propel itself forward. Start by getting commitment for a limited number of human and technology resources to address only a handful of critical business problems. Once you prove it works, slowly ask for more resources to attack more problems. Over time, you’ll be able to grow a stable, accepted analytics research and development function. You just have to push through the initial misunderstandings and the resistance to the unknown.

I think you’ll find, like I have, that very few people will argue against the merits of research and development as a business endeavor. The first step in the process of enabling discovery analytics at your organization is to ensure that people understand that you’re just talking about a different type of R&D effort. You’ll still have a lot of work to do, but at least people will be willing to listen to you make your case and hopefully give you a chance to show what you can do.

Discovery Analytics: It’s Not Hacking, It’s R&D, by Bill Franks

DiscoveryAnalytics

It’s Not Hacking, It’s R&D

Bill Franks has clarified the valued use of R & D as a reframe for pre-planning, analysis and pre-testing with this article. https://www.linkedin.com/pulse/discovery-analytics-its-hacking-rd-bill-franks

I spend a lotBillFranks of time these days talking with companies about the need for a formal approach to enabling what is often called “discovery analytics” or “exploratory analytics.” What I find is that many people have a fundamental misunderstanding of what discovery analytics is all about. There is one analogy that I have found to be effective in getting people to better understand the concept. In this blog, I’ll walk you through that analogy.

IT ISN’T AIMLESS HACKING!
Many people get very concerned when I begin to discuss discovery analytics as being not fully defined, constantly evolving, and remaining fluid. They tell me that what I’m saying sounds a lot like a mad scientist sitting down running random experiments in the hope of finding something useful. I do not espouse such an approach, I can assure you!
On the contrary, a discovery process should always start with a specific high priority business problem in mind. There should also be at least a general idea of how to address the problem effectively through analytics after some initial brainstorming. At that point, a discovery process is started to explore how well our ideas actually do address the problem. Typically, a discovery process involves one or more big unknowns:

  • We may be addressing a totally new business problem
  • We may be utilizing one or more new and /or largely untested data sources
  • We may be making use of analytics techniques that we haven’t used in the past

In short, while we think a proposed approach has merit, we really don’t know for sure how well it will work. The only way to find out is to dig in and see what we find. As a part of that process, we may well adjust our approach across any number of dimensions. The final solution we find may be somewhat different than the path we started down, but it will be found by remaining focused on the core problem we start with.

WE’RE REALLY TALKING ABOUT RESEARCH & DEVELOPMENT
If analytics is going to be a strategic component of your business, then you need to invest in analytics just like you do for other core products and services your company offers. Discovery analytics aren’t mindless hacking any more than traditional research and development activities are. People accept that an R&D team will have to be creative and try many paths to identify a winner. At first glance, some say that this is acceptable in a traditional product setting but not in a discovery analytics setting. I suggest that it is important to realize that the two are the same.
One of our high-tech customers takes only take a handful of new products to market in any given year. However, massive investments with many trial and error experiments happen behind the scenes to get those products ready. At the other end of the product complexity scale, quick-serve companies only bring a few new menu items to market each year. In their test kitchens, however, a never-ending stream of new recipes and ingredients are explored to arrive at the winners that make it to your local restaurant.

Discovery analytics are much the same. A variety of attempts will be made, of which only a few will turn out worthy of a full deployment. But, those that are worthy will have a high level of strategic value if efforts are focused in the correct areas of the business up front. Some ideas may not work out at all and will have to be abandoned. I’m sure there are also many computer chips or chicken sandwiches that never made it out of the R&D process either. Not every effort will turn into a winner, but working through the losers is the only way to get to the winners. In fact, if your analytics do not generate some losers, something is wrong: either they aren’t being made known, or the analytics team is not continuously pushing the limits of innovation.

RAMPING UP YOUR ANALYTICS R&D FUNCTION

It is critical to redirect discussion on discovery analytics toward the R&D parallel. People are much more comfortable with R&D because it is viewed as a rational, scientific, disciplined approach to developing new products and ideas. Discovery analytics is just that. Of course, it takes ongoing effort to ensure that any R&D function stays on the right path. With correct oversight and leadership, however, there is no reason your organization can’t reap large benefits from discovery analytics over time.

The best thing about building up an analytics R&D function is that it will self-propel itself forward. Start by getting commitment for a limited number of human and technology resources to address only a handful of critical business problems. Once you prove it works, slowly ask for more resources to attack more problems. Over time, you’ll be able to grow a stable, accepted analytics research and development function. You just have to push through the initial misunderstandings and the resistance to the unknown.

I think you’ll find, like I have, that very few people will argue against the merits of research and development as a business endeavor. The first step in the process of enabling discovery analytics at your organization is to ensure that people understand that you’re just talking about a different type of R&D effort. You’ll still have a lot of work to do, but at least people will be willing to listen to you make your case and hopefully give you a chance to show what you can do.

Inverting the Test Pyramid, by Joel Masset

Great Article from Joel Masset, Global Head of Product Assurance and Chief Quality Officer in the Financial Services Industry

invertedpyramid
Inverjoelmassetting the Test Pyramid
by Joel  Masset
https://www.linkedin.com/pulse/inverting-test-pyramid-joel-masset

Although most organizations focus on what it means for development teams to be agile, what that changes for them, and how to make it happen, testing is still very important in an agile delivery model. It is even more critical than in a traditional model.

I want here to highlight the big change that agility represents from a testing point of view. This is highly inspired from Mike Cohn’s well known test pyramid. However, I thought it was worth sharing this once more, as it is so close to what many major software delivery organizations need to go through nowadays.

In a traditional software delivery approach (waterfall, V cycle, iterative V cycle, washing machine…), all activities are serialized. Business requirements, design, development, test, debugging, […], release. The focus is put on finding bugs.

InvertedPyramid1

This leads to very little test effort to happen at the beginning of the cycle, and massive focus at the end, after developers have integrated their components into a product.

Roles are very clear and distinct. Developers’ role is to code and debug, testers’ is to find bugs, and check they are fixed.

Automated tests developed after the integration has happened will be essentially based on the UI. Their development cost is very high and since they are very fragile, maintenance costs are very high too. Any update to the code is likely to break the tests, which will require automation code to be updated prior to being ran. Since most of the testing focus is happening so close to the expected delivery date, there is a lot of pressure on the team to give its test campaign results. In most cases, it results into massive manual testing. In the best case, automated test development will happen in parallel, so that these can run post the release, but very regularly, the team will just give up on automating.

As a result, automation is extremely painful, costly, and inefficient, with a very low Return On Investment. The manual testing in this model is very costly, and happening under stress.

Don’t get me wrong, I am not saying this model cannot work, I have myself been using it for years. But oh my god, is it stressful…
Agile testing takes the opposite approach, by inverting the test pyramid.

AgileAutomatedPyramid

The focus is now put on preventing bugs from existing. This means that most of the test effort will happen at the beginning, at the code and UI level. In this context, automation will be extremely efficient. Unit tests will be written alongside development, or even before the actual code is written or updated (this is the Test Driven Development model).

Acceptance tests will be created at the API layer level during development and integrated in the continuous build and integration tools and processes.

At the time the developer checks the code in, it has already been successfully tested. Post-build and integration tests will automatically be ran and results checked.

Since all those tests happen during the sprint, a failed test will immediately lead to a code change fixing the issue. Not only the cost of fixing a problem is much smaller at this stage, but the risk associated to re-opening code that was already pushed, days or weeks ago is gone. The team then rarely has to switch context from the current version of the code to an older one. This is a much more reliable process.

Some testing will still be required after the integration steps. Some will still be automated at the UI level. This represents very boring and repetitive tests like links checks, or basic user workflow steps. The essential part of testing at that stage is exploratory testing. Based on end user workflows, these are tests that only a human person can do. But the effort will be limited here.

In this new approach, you end up with developers and testers both testing and coding together. A much higher synergy, and very little stress, because the delivery process is made much more reliable.

Results are impressive on the Quality of the software, the predictability of the releases, and as well on the motivation of the teams.

This change requires a big cultural change obviously, hence very high senior leadership, this will certainly be the focus of a future article…

Bill Fulbright
770-880-0959
Bill@2100solutions.com

Platform Service Transformation: Entry 2 – Platform Architecture and ReDesign: Phase One

ArchitecturalView  

Platform Architecture and ReDesign: Phase One


2nd Entry

The purpose of this project is to unbind and unfetter a great service and product from debilitating, confusing and circuitous code. As in many cases, the code for products, is a result of many years of different code practices, developers, loss of methods in favor of “quck-fixes” to support Production. The result is a hairy, overgrown, complex, and code with nothing but dead ends in its future (in other words, non-scalable, with too many hard coded restrictions)

The Challenge is to re-design and construct a new infrastructure that IS scalable, flexible and elegant, without the User Experience changing. It may be improved, but for a more intuitive work flow’s sake, retaining the functionality on which the customer base is dependent.

The Tool Stack being used in current project for code re-factoring and re-design:
In order to transform a platform riddled with inefficient code, and work flow paths, we are consolidating DB Calls and Posts, using the following to create new service based middleware (to replace the PHP assignments): Cloud based iterations for DEV, DEVOPS, R&D, Ruby, Java, RAML for new APIs, ElastiSearch, Kibana, Jenkins, Cucumber, PHP (unraveling and re-assigning), Version One, Apache, Oracle, customized code generation, common sense, and Top-Down development and sensible deliveries for each sprint. Each of the teams (2 – Dev, UI/Biz) own their parts, and there are also intersects between the team functions for each team member. Some more than others.

CloudArchitectureMap
Example: NOT Actual

While we have spent a good bit of time re-engineering the product, we have realized, that we are limited in our demos to reflect the present level of functionality based upon the existing product. In order to fully service the needed functionality at the needed scale, we will begin development from the Top Down, rather than the discovery based Bottom Up approach. The Bottom Up approach has been useful in revealing many of the flaws, design complexities and inefficiencies, and workflows. This realization also provides the reality of NOT developing certain functional sections such as Security – already complex, into a flawed model. Once the present demo is completed to demo for execs, the functionality based upon the Bottom Up approach will be retained, but developed from the Top Down.

This shift in approach will allow implementation of complex features from a fresh start, designed to scale, and efficient.

Next Entry coming soon!

Vendor Management Service Transformation: Entry 1 – Re-Factoring, Businss Architecture

metodo_pratiche_agile_chart_manifesto_itaEntry 1    3.22.2015

I recently was invited to join a project for a Vendor Management Service (VMS) in Mid-March 2015. The project is to provide in Phase 1 a re-factoring of our Client’s code by replacing the hardcoded middleware with services, and adding new client facing features, along with a new UI. All needing new documentation, of which there is now verylittle.

Our client provides a turnkey service for managing IT vendors who need to outsource their HR, Recruiting, Accounting, and Financial Services for this aspect of their business.

My role is to document the present legacy Business Processes, the new Processes, the new Services and the newly re-factored APIs, processes and added features by providing the Requirements, Use Cases, Workflows and Processes.

The leadership on this project is not only setting the pace, but shining a bright light into the future vision for this client, and for the VMS industry. It is a privilege to work with them.

 

Presently, I am awash in the project ramp-up and assimilation of the many layers, features and infrastructure required to successfully launch a program as complex as this.

We have two teams: one is onsite with FTE EEs of the customer, and a fly-in contingent of our leadership. The other is an offsite team in Atlanta, that is providing an AGILE based component for delivery of the new code which provides the new Service APIs and integration; as well as Leadership, Business Architecure, Process Articulation & Documentation. The client will observe the present SDLC based approach for now.

We have defined the primary users and their roles, the features – both new and old – associated with their roles. The functionality of these features some of which, for now, will remain as legacy, while others are new. There are around 400 of these. Some are Epic, requiring some of the features to support the workflows.

For the new and replacement pieces (in AGILE) we have defined the primary “Day in the Life” from the “need to the ass in the seat” E2E process to establish a critical Happy Path. Variations and UCM will be modeled based upon this primary structure.

The software and coding will be the same, albeit updated. The specific usage of the system will vary based upon the needs and systems of client-users of this system.

The SDLC pieces for things like the DATA, and QA will be driven from the client sites.

I will be updating this log at various points along the way…. so STAY TUNED!!

Bill Fulbright

Want To Start a Testing / Delivery Practice?

cropped-qa2100_gravatar.pngSo many of us do.  However, looking at starting something like this from scratch, is truly starting a new business and requires much thought, planning and many “hats”.  Here are some points I have used to assist others in grasping the needed vision, depth of effort, types of talent, and sustainability of the effort that will be required.

Visit my Linked In group at:  QA 2100 Testing: Financial Services

Roles and Resources
It requires full time attention to each of these Roles and Resources:
1.  Experienced and Qualified Prospecting and Sales force
2.  Pre-Sales Preparation, RFP/RFI Replies, as well as Attendance at Presentation (Orals) – for each opportunity.
3.  Attained Status as Preferred Vendor, or Vendor
a.  Requires relationship with Client Companies
b.  Requires meeting their criteria for becoming a vendor
1.  Capacity to perform
2.  Liability Insurance
3.  Fiduciary Responsibility
4.  Legal Compliance
4. Developers for the domains you wish to pursue, with the appropriate skill sets, and experience
5. Business Analysts and Business Architects for the domains you wish to pursue, with the appropriate skill sets, and experience
6.  QA Leaders, Managers, and Testers with domain experience
7.  Project / Engagement / Delivery Managers to connect with the Client and the Teams
8.  Financial Resources to sustain the ramp-up of business, infrastructure, and delivery of services
9.  Financial Resources to sustain Market Research, Marketing Strategies
10.Partnership Alliances – to give you value added leverage when positioning for new business
11.Budget that will include all the above, balanced with enough sales to justify the effort, or a plan for ROI over 5 years for investors.
12.Business plan and road-map that demonstrates all the above, and it’s veracity.
13.Staff on the ground – available, ready to work on-site, near-shore, no visa issues, or proven offshore teams that have a solid delivery history.

I am writing this not to discourage those interested in pursuing such a goal, rather to create curiosity and and interest in taking on the challenge.   These concepts and work efforts are real elements that have to be in place before it can be a successful venture…. even for an established company wanting to build a new practice.

Business Plans:
In other words, this effort requires at least:
Experts to Initiate, Drive and Deliver
Business Concept(s) meeting Market needs; Business Need/Justifications
Planning: Initial Steps to Initiate, Milestones at 3 mo., 6 mo., 1 yr, 18 mos., 2 yrs., etc. till 5 years
Identified Services and Products
Multi-Phase Financing: Start-Up Money, Mid-Term Money, Long-Term Money, Planned ROI’s for each phase
Market Research for Service / Product Viability,
Strategy for Launching the Business,
Scope of Ramp-up,
Planned New Business Market(s)
Planned Costs
Ability to Staff and Deliver
Motivation, Determination, Desire, Mission and Purpose
Commitment to see it through

None of these comes pre-packaged, or comes easily.  It all requires vision, leadership, experience, clarity, strategy, good communication, follow through.

I am certainly not giving away the store here, but sharing some thought work I have used to help prepare business not only in the IT world, but as part of my 12 yrs of Management Consulting before my last 19 years in the IT business!  These principles hold true in any enterprise!  I have written many accurate and successful business plans for new or international or established companies seeking investment money to fund a start-up.

As a thought leader and architect of Quality Assurance, and Business Process, I have learned through experience these tenets, which will not be learned so much at school, but by living it and delivering it – with successful outcomes.  That does not mean there weren’t failures, or massive challenges along the way – that is where the real learning takes place.

Sneaky Gollum

Security in 2015 – What measures will be implemented to improve it?

by ,  Sr. Quality Strategy and Delivery Advisor

Is Security in your environment covered?

  • Do you have a full rundown/analysis of the gaps you may have in your system?
  • Have you created a checklist of all:

    • touchpoints
    • protocols
    • profiles
    • methods of transmission
    • firewalls
    • frequency of sweeps
    • frequency of security monitoring status reports?
    • Do you have a network ops monitoring application?

imageThis is not the year to be avoiding the security risks afoot … not only from your own employees, random local hacker, but serious international hacking as pro-active attacks on your system. 2014 demonstrated an increase in security leaks – or might i say exposure of weak security by upstream hackers with malicious intent. Expect more of it. Breaches have been happening every year for some time. We are no longer surprised by them. It is another overload of input that we as consumers can do little to prevent.

Prevention of security leaks are up to those responsible for maintaining our private accounts and data. That they have allowed weaknesses that are gaps, and hackable, is irresponsible, unacceptable, and once leaked causes much damage financially, and personally.

What is a Threat Agent?

The term Threat Agent is used to indicate an individual or group that can manifest a threat. It is fundamental to identify who would want to exploit the assets of a company, and how they might use them against the company.  You can read more about it here:
https://www.owasp.org/index.php/Category:Threat_Agent

Here are some Highlights from Open Web Application Security Project “Attacks” references:
https://www.owasp.org/index.php/Category:Attack

Looking forward to seeing deeper security measures, and fewer assailable gaps by our financial institutions and retailers.

All comments invited.