Axispoint, 3rd Fastest Growing US Tech Company, Drives Growth with Innovative Blockchain Offerings

Axispoint, Inc. ranked third on the Fast Growth 150 list by CRN® but it’s what they’re doing next that will change the game.


Blog-feature-CRN-fast-growth-150.png

New York, NY, October 15th, 2018 – Axispoint, Inc. announced that CRN®, a brand of The Channel Company, has named Axispoint the third fastest growing company on its Fast Growth 150 list. The list is the annual ranking of North America-based technology companies with gross sales of at least $1 million that have experienced significant economic growth over the past two years.  In addition, Axispoint was also featured on CRN’s Solution Provider 500, an annual ranking of the largest technology integrators, solution providers and IT consultants in North America by revenue. The combination of the two awards highlights Axispoint’s ability to grow significantly with scale.

“We are thrilled to be recognized by The Channel Company for our notable increase in client project execution” said Axispoint’s President and CEO, Daniel DiSano. “The Fast Growth 150 list includes some of the most distinguished North American technology providers, and it’s both extremely gratifying and an honor to be included. Our teams of subject matter experts and technologists are dedicated to the company mission of providing practical solutions using the latest information technology innovations.” DiSano continued, “I thank The Channel Company for their ongoing commitment to the IT industry, and I congratulate our esteemed peers on the list.”

Axispoint is a leading custom application development company headquartered in New York City with global operations.  Axispoint builds enterprise-grade and innovative software for well-financed start-ups to Fortune 500 companies. Though vertically agnostic, Axispoint has deep domain experience in music, media and sports and technology companies.  

Media and entertainment, in particular, has a pivotal need for a strong, end-to-end partner in the content creation and management process. In 2017, Axispoint acquired T2 Computing (formerly Tekserve) allowing the combined companies to offer coordinated subject matter expertise as a single provider solution.  The acquisition provides scale and a full stack solution offering for content companies - from upfront consulting and software development to infrastructure engineering services and core media products.

What’s now and next?  Axispoint has been an early adopter of blockchain and has launched a full service blockchain development practice with the objective of being one of the leading blockchain providers worldwide.  Axispoint is currently building innovative blockchain solutions for companies across industries. There are numerous robust use cases for blockchain where customers want transparency, clarity, immutability, efficiency gains, improved transaction and payment processing, reduction of middlemen, and so forth. Axispoint’s expertise in building enterprise software now coupled with blockchain technologies allows the company to be at the forefront of customer innovation.

“We’re not your typical blockchain startup. Axispoint is an established company leveraging 20 plus years of industry experience and a proven track record of solving complex problems.” said DiSano. “By adding blockchain capability over the past year, Axispoint is well positioned to continue to offer world class software solutions for our customers, leading to significant growth in the years to come.”

Coverage of the Solution Provider 500 and Fast Growth 150 was featured in the June and August issues of CRN, respectively, and online at www.crn.com.

About Axispoint, Inc.

Axispoint delivers custom software and consulting services to the world’s top content companies. In partnership with our clients, who range from start-ups to global 1000 enterprises, Axispoint combines domain expertise, strategy and the latest technologies to convert business visions into valued solutions. Established in 1994 and headquartered in New York City, Axispoint provides a range of talented technology professionals from across the US, Europe, and South America. Axispoint is consistently recognized for industry leadership, innovation and growth.

www.axispoint.com

About T2 Computing

T2 Computing is a technology solutions provider focused on the creation, management, distribution, storage and monetization of digital content.  T2 provides high skilled infrastructure engineering and strong technology product know-how to help design, procure, implement, manage and support systems for the leading media companies in the world.  T2 is also a trusted Apple partner, providing an innovative "Apple in the Enterprise" service to manage the Apple environment of companies across industries.

www.t2computing.com

Contact:

Axispoint, Inc.

Kate Kelly

212.920.2600

info@axispoint.com


Cadent COO: Blockchain Is A 'Long-Term Growth Play'

Cadent’s Stephanie Mitchko-Beale implored solution providers at CRN’s 2018 Best of Breed Conference to get behind blockchain, saying that it’s a “long-term growth play” that can improve transparency in business.

CRN-Logo.png

Published on CRN (https://www.crn.com)
Cadent COO: Blockchain Is A 'Long-Term Growth Play'
by Dylan Martin on October 09, 2018, 07:46 PM EDT

Blockchain is a "long-term growth play" that solution providers should get behind, according to Stephanie Mitchko-Beale, a veteran media, technology and advertising executive.

Mitchko-Beale, CTO and COO of New York-based adtech firm Cadent, made the case for the distributed ledger technology in a Tuesday panel at The Channel Company's 2018 Best of Breed (BoB) Conference in Philadelphia. She was joined by Dan DiSano, president and CEO of Axispoint, a New York-based solution provider that has begun developing blockchain-based applications and is No. 296 on CRN's 2018 Solution Provider 500.

Axispoint is among a small group of solution providers that have started working on solutions based on blockchain, the technology behind Bitcoin that some enterprises now see as a transformational technology for bringing more trust and transparency into business.

"Blockchain is perhaps the hottest technology right now in the development community and the C-suite world," DiSano said. He admitted that the technology is still early, like how the Internet was nascent in the mid-1990s, but he said, "it's not early in terms of investment."

Bruce Lehrman, CEO of Cedar Rapids, Iowa-based Involta, No. 326 on CRN's 2018 SP500, said he doesn't see his company taking on a blockchain application development role. Instead, the company will more likely adopt the technology through its vendors in the future.

"We're kind of users of technology, we're not creators of technology, so I think it's interesting. It's fundamentally going to change a lot of things that we do, but we'll be a consumer of it, not a creator," he said.

Lehrman said Involta has had some conversations about blockchain with customers, but he admitted "it's still too early on for most of the business users."

Mitchko-Beale acknowledged that it's early in the adoption cycle for blockchain, but she said the technology has the potential to disrupt "every industry under the sun," including advertising, media, pharmaceutical and cosmetics.

"Any distribution network where you need to track what's going on is an application," she said.

Walmart, for example, has started requiring lettuce and spinach suppliers to join the company's food-tracking blockchain powered by IBM to help pinpoint sources of food contamination and, as a result, accelerate and improve the product recall process.

"It's a distributed way of keeping a ledger where each component in the block is encrypted along the way, and all the constituents have visibility, and identity is apparent and transparent," Mitchko-Beale said.

DiSano said his company, Axispoint, started getting inquiries about blockchain 11 months ago, and now the company is working on multiple projects, including a real-time trading platform that is based on a private blockchain.

"We're seeing a lot of development work," he said.

Mitchko-Beale said she’s had a budget for research and development and investigation of blockchain proof of concepts for the last two years. While she said her company has yet to invest a lot of money or seen a return on investment in blockchain yet, she feels that it's still important for Cadent to stay ahead of emerging technologies.

"I think it's a long-term growth play," she said. "It's a technology, and people will figure out over time on how to use it in a whole bunch of ways, ways we haven't even thought about today."

CRN Blockchain Bonanza: Solution Provider Say The Technology Behind Bitcoin is 'The Real Deal'

CRN Title.JPG

Published on CRN (https://www.crn.com)
Blockchain Bonanza: Solution Providers Say The Technology Behind Bitcoin Is 'The Real Deal'
by Dylan Martin [2] on June 11, 2018, 12:00 pm EDT

 

Dan DiSano felt like a rock star.


Standing in front of hundreds of people, the president and CEO of New York-based solution provider Axispoint was pitching a new blockchain development practice to potential investors at a South by Southwest event earlier this year in Austin, Texas.

The response that followed told DiSano he was on to something.

"It was literally like a Beatles concert. There was a stampede of people waiting in line to meet with us," said DiSano, noting that the company plans to raise a round of financing from investors later this year. "That made it real because there were real investors there who said, 'When you're ready, please send us all of your documentation.'"

Blockchain, frequently talked about in the same breath as Bitcoin, is the distributed ledger technology that powers cryptocurrencies. It quickly gained buzz over the past year as hundreds of cryptocurrencies went online and the value of one Bitcoin surpassed $20,000 last December (today it's closer to $7,400). But some enterprises have been plotting out blockchain's second life: as a transformational technology that could bring more trust and transparency to businesses.

Solution providers and other industry observers say the applicability of blockchain goes far and wide [3], with the potential to impact banking and financial markets, insurance, retail and consumer goods, health care, government and transportation, among other industries. A report by research firm Gartner last year estimated that blockchain's business value-add will grow to $176 billion by 2025.

Today, the technology is still nascent. A recent Gartner survey showed that only 1 percent of more than 3,000 CIOs already have blockchain deployments within their organizations while another 8 percent were in short-term planning or experimentation with blockchain. More telling were the 77 percent of CIOs who said they either have no plans or no interest in deploying the technology.


To the channel, that's just a sign that businesses are only starting to understand blockchain's potential impact, which is why solution providers are making early investments and launching new practices around the technology now. Global IT consulting firm Accenture started exploring blockchain a few years ago, and it now has multiple projects that have been publicly announced with the United Nations, Microsoft, the Canadian government and AB InBev, among other big  layers. Joseph Francis, a principal director at Accenture, No. 2 on the 2018 CRN Solution Provider 500 [4], said he can't think of a time when dozens of clients haven't been asking about blockchain over the last year and a half. "I haven't had a single customer who hasn't had a conversation," he said.

For Axispoint, No. 296 on the 2018 CRN Solution Provider 500 [4], the benefits of launching a blockchain development practice a few months ago already are starting to show. The company is in various stages of discussions with 10 customers, according to DiSano. In one project, Axispoint is providing $30,000 of up-front consulting work to produce a report on the customer's strategic direction so that it can go out and raise funding. Axispoint also is working on a $400,000 contract for a larger $10 million project to build a platform for a financial services client. "You definitely do see the hype in the market, but blockchain technology is the real deal," DiSano said.


Life Beyond Bitcoin
Blockchain has been likened to the building blocks of the internet, similar to the TCP/IP and HTTP protocols that paved the way for the World Wide Web. "I think blockchain is going to become a really common tool in every IT stack, and I think to ignore it would be a big mistake. It would be like ignoring HTML," said Karen Kilroy, CEO and founder of Austin-based Kilroy Blockchain, which provides a blockchain platform-as-a-service for enterprises.


The technology was conceptualized in 2008 as the public transaction ledger for Bitcoin by Satoshi Nakomoto, the pseudonymous creator of the popular cryptocurrency whose true identify remains a mystery. Since then, the number of cryptocurrencies has ballooned to more than 1,000. It's called "blockchain" because of the way that transactions are stored in encrypted blocks, which are linked together in a chainlike manner, lending to blockchain's tamperproof qualities. These transactions are conducted on a distributed network, which can be public, like cryptocurrencies Bitcoin and Ethereum are. Or it can be private, which means that participants must be invited to join the blockchain. These networks are peer-to-peer, consisting of nodes that collectively maintain the ledger and its history of transactions. Now people have begun talking about the concept of "blockchain 2.0," which involves moving the technology beyond its use as a ledger for cryptocurrencies. It turns out that blockchain's major capabilities meant it would have applications for storing information and recording transactions among multiple parties that weren't strictly financial.


"One of the really nice things that blockchain does is [provide] a single source of truth among a large group of companies," said Accenture's Francis. One of blockchain's key features is immutability, meaning it is difficult to tamper with records. There's also the requirement of consensus -- gained through protocols, algorithms and mathematical proofs -- among a blockchain network's nodes to execute transactions. Then there's the use of so-called smart contracts, which allow for rules and conditions to be programmed into the network for different transactions.


"I think blockchain over time is going to show you a number of features, like speed, cost savings, creating trust, creating transparency," DiSano said. "It's very rare a technology can do all of those things at the same time, in addition to being incredibly secure." Another key takeaway for solution providers is that a blockchain is only useful if the customer is looking for a way to share information among multiple parties.


A Way To Differentiate
When Converge Technology Partners acquired Ottawa-based Becker-Carroll earlier this year, the Toronto-based solution provider saw it as a major opportunity to enter the blockchain space. A developer of digital services, Becker-Carroll already had multiple blockchain deployments with government entities focused on identity management.


"We just felt like that's an overarching asset that adds to the portfolio companies within Converge, so we felt like it was truly a differentiator," said John Flores, executive vice president of marketing and strategic alliances at Converge Technology Partners. For its public-sector clients, Converge Technology Partners is working on blockchain based identity management solutions that would allow government agencies to share records over a secure network.

"There are a lot of trends and external factors, like [the European Union's General Data Protection Regulation], that are driving this necessity for clients to look at this, and we're seeing a lot of demand in government entities and interest specifically in that vertical," Flores said.


Luis Morinigo, practice lead and business development director for the Internet of Things and advanced analytics group at New Signature, said his company started considering blockchain as New Signature evolved into "an applied innovation practice." As a Microsoft partner, the Washington, D.C.-based solution provider took notice of how the vendor was approaching the technology through its Coco Framework for blockchain.


"There are a lot of activities you can manage off the blockchain and use it for what it's meant to do: an immutable record-keeping system for all the actions that an organization takes," Morinigo said.

New Signature has been approaching blockchain with a platform mentality because it requires multiple stakeholders for any one deployment, according to Morinigo. He said there are opportunities for businesses to be either the "platform builders" or the "platform members," the latter of whom would join a blockchain network that is being hosted by the builder.


"If you're a leader in the space and want to be the platform builder, that gives you an advantage because you're opening up a marketplace for all of the entities that you interact with every day, and you can charge a fee for that," Morinigo said. "But if you're one of those entities that is a member of the consortium and you're using the blockchain that a platform builder has made available to you, you get advantages from that. You didn't have to invest in the process of building that platform."

Solution Providers Find Vertical Market Use Cases
Accenture's Francis said the firm sees supply chain as a major area that can be disrupted by blockchain. He recently published a report about how the technology could address the "hall of mirrors" problem in a supply chain, where multiple parties have copies of the same documents, making it difficult and time-consuming to reconcile information. "That's a fairly arduous process," Francis said, which is why he believes the solution lies in blockchain's ability to provide "data mutualization," where all of the documents held among multiple parties match each other and can be reconciled automatically.


"It enormously reduces the cost associated with managing the data itself," he said. 10th Magnitude, a Chicago-based solution provider and top Microsoft partner, is currently working on blockchain projects for two clients. The first client is a manufacturer of landscaping equipment that wants to find a way to deliver secure, trustworthy messages to customers of its connected products. The second client is exploring blockchain as a way to create a tamper-proof record of fire inspection reports.


"That's not something you want to have tampered with," said Mark Johnson, a solutions
architect at the firm. Kilroy Blockchain, whose IBM-based platform helps regulated companies connect their existing software to a blockchain, is currently working with a customer in the real  state space that is using the technology to provide an immutable audit trail for transactions.
"Each participating party can have their own copy of the audit trail to keep everyone honest," Kilroy said.

Vendors Have Plans For The Channel
IBM became one of the early movers in the enterprise blockchain space when the Armonk, N.Y.-based company's research lab began looking into potential use cases, according to Janine Grasso, vice president of blockchain strategy and ecosystem at IBM. One of the results was a blockchain-based food safety system that can reduce the time to identify a contaminated food's source from weeks to seconds, meaning that stores would be able to limit the scope of product recalls. "If there was a contamination because they didn't know where it came from, they would
have to remove all of the product -- millions and millions [of dollars] of wasted food," Grasso said. With blockchain, she added, "that overall market will see benefits in the billions."


Now IBM offers a full blockchain development platform that aims to lower the barrier of entry for developers. Grasso said IBM has provided the tool for free to channel partners and that several joint initiatives are under way, though she declined to identify any of the partners.


"I've talked to dozens of partners, whether global systems integrators or value-added resellers or distributors," she said. "They're all trying to figure out where their place is in this ecosystem." Grasso said it's important that solution providers position themselves to their strengths. She said a lot of channel partners have already attended IBM's webinars and enablement sessions to figure out how to position themselves and their own offerings.


"If you're in manufacturing, you have suppliers and consumers that can use this technology," she offered as an example. IBM is among a handful of vendors that have begun offering blockchain software tools aimed at channel partners, a group that also includes Microsoft, Amazon Web Services, Hewlett-Packard Enterprise and Oracle, as well as startups like BigchainDB and Stratis.
Frank Xiong, group vice president of blockchain product development for Oracle, said the company has been working with channel partners who have been using a beta version of the Oracle Blockchain Cloud Service, which has an official release this summer. Early adopters include Accenture, AuraBlocks and IntellectEU.


"My view is that there will be a great opportunity, because we sense there is a lot of need for integration and customization and hooking up things together among different ERP applications and supply chain applications," he said. 


Revenue Opportunities
For solution providers putting an early stake in the blockchain ground, the financial opportunities are both lucrative and varied. Johnson at 10th Magnitude said his firm started working on proof-of-concept projects in the past four to five months, and that they can range in cost from $15,000 to $30,000. The solution provider is taking a wait-and-see approach on how to price live production environments. "Right now, most production environments for blockchain won't have much usage right away," he said.


When it comes to the specific revenue streams for blockchain projects, it depends on the kind of solution provider and the nature of the project itself. Don Cuthbertson, CIO at Converge Technology Partners, said professional services and integration services present the largest revenue opportunities. He said there is also an opportunity to bring in managed services revenue for clients that can't manage their own networks.


Oracle's Xiong said for businesses operating their own network, they can decide whether to charge per member or per transaction. "Once they build an application on their blockchain platform, it's up to them to charge each member joining for a monthly fee or per transaction," he said. It's for that reason, IBM's Grasso said, that owning the blockchain network -- meaning that the business is responsible for the governance and manages ownership -- presents the largest revenue opportunity. "Owning the network would have more financial reward then just being an adviser," she said.

No Pain, No Gain
While blockchain offers some new revenue streams, Converge Technology Partners' Cuthbertson cautioned that some blockchain projects "may be a bit of a loss leader" at the consulting stage because the technology's steep learning curve can make it difficult to justify billing for all the hours spent discussing it. "From my point of view, there's definitely information that's not well understood about what blockchain is, what it can do, what it's for," he said.


Solution providers need to help clients see which types of problems can be solved by a blockchain-based network, said New Signature's Morinigo. "If you're building a blockchain platform for just your organization, there are very few use cases where that makes sense, and you're most likely overengineering a solution that could have easily been addressed by a bunch of SQL servers," Morinigo said. 10th Magnitude's Johnson said he's seen clients who don't yet understand blockchain's use cases or tradeoffs. For example, a couple of clients had told the firm that they believed blockchain was a great opportunity for their businesses, but 10th Magnitude
determined it likely wasn't the right fit.


"We asked, 'Why, and what's your use case?' and we find out it's something like a high performance rapid transactional database," Johnson said. "If you want that, go for a SQL Server." But for any obstacles that come with adopting new technologies like blockchain, Morinigo said it's worth it in the long run for solution providers.

"There will be some growing pains in the process of thinking about where one fits in the innovation space," he said. "But in my opinion, if you don't go through those growing pains, the pain further down the line, five years from now, will be greater." Axispoint's DiSano said he's been to multiple conferences where CEOs of major companies are saying boards across the country are going to have to consider blockchain in one capacity or another by the end of the year or else they might experience disruption. "Blockchain is not a fad. It's not the next shiny little object. It's a real technology," he said.

Source URL: https://www.crn.com/news/internet-of-things/300104871/blockchain-bonanza-solutionproviders-say-the-technology-behind-bitcoin-is-the-real-deal.htm?page=0%2C4


Links
[1] https://www.crn.com/news/internet-of-things/300104871/blockchain-bonanza-solution-providers-say-thetechnology-
behind-bitcoin-is-the-real-deal.htm
[2] https://www.crn.com/author/dylan-martin
[3] https://www.crn.com/slide-shows/internet-of-things/300104876/8-hot-blockchain-vendors-solutionproviders-
should-check-out.htm
[4] https://www.crn.com/sp-500/2018/index.htm

Best Practices

Best Practices


Requirements Definition

We believe in a just-in-time, just-enough level of analysis and requirements definition, and undertake the following process:

  • The Product Owner, along with the Business Analyst and UX Designer will develop the prioritized backlog of user stories that will serve as the basis for development planning during Development phase.
  • For stories requiring a user-interface component, prototypes will be built in lieu of lengthy written requirements.  Prototypes will be supplemented by other visual models where necessary (e.g. state diagrams, class diagrams, sequence diagrams), graphical visual designs, and supplementary written functional requirements (e.g. business rules) if necessary.
  • For stories with a light-to-no user-interface component, functional requirements will be documented, including the use of visual models.

Typically, functional requirements and user-interface designs will be elicited and documented in the sprint prior to planned commencement of development, and reviewed with necessary stakeholders throughout that sprint. 

 

We test continually throughout development, and our stories are validated within the sprint before they can be considered "done".  

Developer Testing

Developer testing covers unit and integration testing. Unit tests are run automatically and after every code check-in to verify newly added functionality and regression test existing code. Integration tests are run automatically and do not test all the business functionality or user interfaces of the application. 

Functional Testing

Functional testing incorporates both manual and automated testing, as follows:

  • Writing of acceptance tests for each user story, based on the story’s acceptance criteria,
  • Writing test cases for each user story, based on the story’s functional requirements,
  • Assembly of test data,
  • Execution of test cases,
  • Logging of defects and validating bug fixes,
  • Automation of functional tests, covering a target of 100% of smoke tests and 100% of sanity tests
  • Automated regression testing of each release, limited to the scope of the automated tests,
  • Sanity testing of each major release.

Non-Functional Testing 

Pertinent non-functional testing is conducted as necessary at various relevant points in the development process: when evaluating or verifying an architecture selection, when basic infrastructure has been established, and when nearing code completion.  Non-functional testing is most often conducted in an exclusive testing environment using tools that are selected during Sprint 0.  This includes high-availability testing and performance testing including load testing, stability testing, volume testing and scalability testing

User Acceptance Testing (UAT)

Most often, our customers will define UAT scripts and execute UAT.  Informal UAT takes place by the Product Owner(s) throughout the Development Phase, in the QA environment, in order to provide early feedback.  Formal UAT takes place during the Production Readiness phase.

Test

 

Deployment

 

Axispoint writes automated deployment scripts for our software.  Deployments to QA are completed at a frequency that supports the agile development and testing process.  We use Jenkins to support the practice of Continuous Integration (CI) to govern deployments, automatically testing code and reporting issues.  The use of Continuous Deployment (CD) varies depending on the client and project maturity.

 

Roadmap for Success

AdobeStock_Roadmap.jpg

Roadmap for Success

Axispoint believes in iterative software development, including incremental rollout of major functionality.  We believe in starting with a MVP and iterating through phased releases.  Enter the Product Roadmap.

1. Roadmap Definition

A roadmap is the foundation for all strategic development efforts. A roadmap can be seen like a product backlog, with Themes in place of User Stories. A roadmap requires management and, like a backlog, should be periodically reassessed for validity.

2. Roadmap Planning and Reassessment

It is critical that roadmaps undergo periodic reassessments to adjust for changes in priorities, any new external business situational changes, and for duration adjustments that are necessary to correct the course of projects. On a scaled project, roadmap reassessments should be formal activities and take place around every three months. Informal reassessment can take place outside of this time frame as information comes to light.

3. Roadmap Grooming and Prioritization

Roadmap Themes must be prioritized according to business value. Where possible, this business value should be quantified to allow for ease of communication and for (somewhat) objective prioritization. Business stakeholders should be consulted for input on business value and on prioritization.

Dependencies between Themes should also be considered, however should not necessarily be a deciding factor in prioritization; if one Theme is dependent on another, consideration should be made to bringing forward the dependent component of the Theme only and not the entire Theme. The efficiency of doing this must however be considered on a case-by-case basis.

The roadmap must also be groomed.  The following activities take place during Grooming:

  • Removing Themes that are no longer relevant.
  • Creating new Themes in response to newly discovered needs.
  • Re-assessing the priority of Themes.
  • Performing an initial estimate of Themes, ideally based on MVP and subsequent work if details are known.
  • Splitting Themes into smaller projects as they become closer to development.

Axispoint can assist in your roadmap development.  Learn more about our Technology Consulting services now.

The Axispoint Engagement Process

Axispoint-Blog-Client-Engagement.jpg

The Axispoint Engagement Process


Discovery

Our business process begins with internalizing your business process

In the discovery phase, we will listen to your specific goals, explore your existing systems, and craft a plan for a technological solution. Expect face-to-face meetings and interactive design sessions with our top analysts, architects and system engineers.

Out of this intensive collaboration, you’ll have a clear schedule and timeline for the project; confidence in our mutual understanding of the problem; and a scope and architecture for a solution that is tailored to fulfill your needs, hopes and wishes. Axispoint’s meticulous discovery process lays the foundation for our future success.

At the close of our discovery phase, we’ll have developed:

  1. a “project vision”, consisting of epics, a model of the project domain and business processes, and the non-functional requirements.
  2. an initial architecture; a high-level design of the software system to be built
  3. a suggested project approach; recommendations on the delivery methodology, including duration, project cadence, and team structure.
 

We know your challenge, and now we pave the road to solve it.

When we have a rough idea of who you are, what you need, and how we’re going to solve it, we begin the development project with a short 1-4 week inception, or "Sprint 0" phase. (If your project didn’t call for a discovery phase, we’ll do most of those activities during this phase instead.)

During inception, we define a prioritized list of features that form the basis of future development work, then organize teams and work environments, ensuring that construction can begin unhindered.

You’ll be introduced to a project team we assemble specifically for you. Your team will work closely with you to ensure the product features meet your criteria before they’re “done,” brainstorm and storyboard user interfaces (the screens that you’ll see and work with in the final product), and prepare you for the construction process. We’ll give you a clear idea as to what we’ll need from you and how you can monitor our progress. Sometimes, we’ll also deem it useful to undertake a prototype or proof of concept to verify that we’re on the right track

At the end of inception, you’ll have:

  1. a prioritized product backlog,
  2. a thorough understanding of the development work that will be completed at the beginning of the development phase,
  3. a scheduled cadence to follow for the remainder of the engagement, and
  4. established development environments.

Inception ensures complete alignment on the expectations and activities during the development phase and will provide you a detailed path to actualizing your software vision.

Inception

 

Development

 

And now... we build

Up until now your big idea has existed in detailed plans and maybe even in dreams.

Development is the phase where it becomes reality… real reality, like the kind you can see. With our agile software development approach, you’ll be able to see working code in as little as two weeks after we begin.

The development phase is made up of successive time-boxed “iterations” (or sprints), where each iteration takes the same form. Typically our iterations last two to four weeks, depending on your project requirements.

Why iterations? We recognize that challenges arise and requirements change throughout the development process. Building a product with non-iterative, whole components, called the “waterfall” approach, makes design adaptation costly and time-consuming - just imagine altering your cookie recipe once they’re in the oven. Iterative design consists of cross-functional teams working simultaneously on a series of features, meaning not only a faster build time, but a flexible and efficient development process.

To begin, an iteration is assigned a series of features to implement in each sprint, the so-called sprint planning. You, as the product owner, will join us in a detailed dialogue about the features to implement in the next sprint, so that you can decide which stories to prioritize. Our team has daily check-ins (“scrums”) where progress is reported and issues can be raised. The features are implemented and tested, and at the end of each iteration, they are presented to you in the sprint demo. We then hand the working system over to you for feedback and review. The cadence is regular enough for you to set your watch by.

And to make sure each sprint is more effective than the last, we take a short time to reflect on what went well and what could be improved (“retrospective”). In parallel, we are also working on defining the details of features that will be implemented in the upcoming sprints by exploring possible solutions, finalizing business rules, and sketching user interfaces.

We keep iterating until your product has sufficient functionality to warrant what we’ve all been waiting for - a production release! And then, if the project calls for it, we keep iterating, building on the first release functionality to make your project even better. At the end of the development phase, you’ll have a consumable product that meets the current needs of your stakeholders.

 

You’ve seen it, you’ve played with it, and you’re ready to let it loose on the world (well, your users at least).

Enter the transition phase, where we successfully deploy the working system into a live and usable environment.

We’ll work with you to determine the logistics and mechanics of the release, such as where and when to deploy, whether the new system will run in parallel with the old, or if any data migration needs to take place.  

At the end of transition your software vision will be fulfilled.

Axispoint can also provide ongoing support and maintenance services beyond the Transition phase.  Our support agreements are as unique as our software, so Contact Us for more info.

Transition

The Agile Business Analyst: A Product Owner’s Best Friend

Axispoint-Blog-agile.png

The Agile Business Analyst: A Product Owner’s Best Friend


Don't Quit Your Day Job

- Written by Elizabeth Taberner-Mair

ElizabethTaberner.jpg
 

There’s so much jargon and lingo in technology that for the everyday businessperson any technology conversation is a difficult and overwhelming experience. But everyday business people have technology needs too. You know everything about your business, but could you translate that into software?

A proficient Agile software development project team depends on a strong and engaged Product Owner to drive the priorities and the product backlog. An effective Product Owner is dedicated and available – do you have the time to be Product Owner for your project? To keep track of the product backlog, answer developer questions, and still fulfill your day job? An Agile Business Analyst can help bridge that gap.

Responsibilities. Let’s start by taking a look at the responsibilities of the Product Owner:

  • Backlog definition: meet with stakeholders to define the product, define product epics (features), define the product backlog, define acceptance criteria for each backlog item, prioritize the backlog;
  • Backlog grooming: identify dependencies between product backlog items, refine and size the product backlog;
  • Define requirements: wrangle details of each story from stakeholders and subject matter experts, support the development of software requirements to meet the acceptance criteria;
  • Support the development process: present the backlog at sprint planning meetings, support developers and testers questions throughout the sprint;
  • Get the product into the real world: accept and sign-off on an implemented story, manage stakeholder expectations…

Introducing the Agile Business Analyst. For those with little experience in software development, this list is long and frightening. The best types of Product Owners are those who understand the true business need of a project and can provide immediate insight to the value and priority of backlog items.
The role of an experienced Agile Business Analyst can support a Product Owner through the
software development process, providing the development team with a dedicated resource which improves velocity and eliminates blocking issues quickly, and leaves the Product Owner to be business focused. Think of them as a Product Owner Peer – or a Product Owner’s best friend.

Agile BA Skills. An Agile Business Analyst is skilled in software development and requirements
elicitation. They know how to ask the right questions of business stakeholders and SMEs and facilitate prioritization with often dissenting opinions. Agile Business Analysts can design software solutions to meet business requirements and that solve business issues, while simultaneously managing the scope of the solution to ensure that the most business value is delivered for the time spent. They can then translate these designs to developers through requirements including visual models.
To the Agile purist, the role of an Agile Business Analyst is an added layer of communication, which goes against the principles of agility. However, someone is always eliciting detailed requirements and communicating them across the team, be it the Product Owner, a developer, a tester… By enabling a skilled resource to complete these activities, developers and testers are freed up to implement the stories.

Technical Chops. The best Agile BA’s are somewhat technical. They understand the software
development process in detail and can contribute to the development of software architecture and design. They are effective at troubleshooting and understand data and how to access it. This technical merit works both ways – Agile BA’s can communicate business needs to the developers in a technical manner, and can communicate technical challenges and solutions to stakeholders in a not-so- technical manner. This relieves a lot of stress for a non-technical Product Owner (that’s what friends are for!). All Agile BAs at Axispoint have a background in software development and technology.

Enables Cost Reduction. The presence of an Agile Business Analyst at Axispoint enables the hybrid onshore/offshore development model (link?). Developers and other team members can be in remote locations, but software requirements are still elicited with direct customer interaction as Axispoint’s Agile BAs work out of Axispoint’s head office. This face time is essential in getting to the core business problems and for brainstorming solutions with stakeholders; the proximity to the customer enables better communication, but costs remain minimized by not requiring this same proximity for the whole development team.

Scrum Ceremonies. Scrum puts an onus on the Product Owner to be present at all ceremonies to facilitate decision-making and provide requirements direction and input. For a time-crunched Product Owner, the Scrum schedule can be a challenge; the Agile BA can be a proxy when necessary. This includes facilitating Sprint Planning (1.5-2 hours, every 2-3 weeks), participating in the Sprint Retrospective (15-30 minutes, every 2-3 weeks), and participating in the Daily Stand-Up (15 minutes, every day). But as the ultimate “Product Owner”, we always recommend that the Product Owner attend the Sprint Demo (1-1.5 hours, every 2-3 weeks) and Backlog Grooming (1-1.5 hours, every 2-3 weeks)!

Like any good best friend, the more investment you make, the better the outcome – so while the Agile BA can be a proxy, the Product Owner should be highly engaged for the best result.

Dividing Responsibilities. Let’s take another look at the responsibilities of the Product Owner, but now divide them between the Product Owner and the Product Owner Peer/Agile Business Analyst*.

Product Owner Product Owner Peer / Agile Business Analyst Together, guided by the POP
- meet with stakeholders to define the product
- manage stakeholder expectations
- wrangle details of each story from stakeholders and subject matter experts
- identify dependencies between product backlog items
- refine and size the product backlog
- present the backlog at sprint planning meetings
- support the development of software requirements to meet the acceptance criteria
- support developers and testers questions throughout the sprint
- define product epics(features)
- define the product backlog
- define acceptance criteria for each backlog item
- prioritize the backlog (final authority coming from Product Owner)
- accept and sign-off on an implemented story

Introducing an Agile Business Analyst to a software development project can make it possible for a customer to achieve the Product Owner responsibilities. By leaving the Product Owner to be business focused and working in a partnership, better quality software can be produced with better velocity, and the technical expertise of the Agile BA makes approaching the development team less intimidating.
Would you like to hear more? Contact us to find out how our Analysts can help your organization through a technology implementation.

Back to the Future of ACID: Part 2

Back to the Future of ACID: Part 2


Borrowing from ACID patterns to tame eventual consistency (continued...)

- Written by Matt Howard

Matt-Howard.jpg
 

In Part 1 we explored the notion of data consistency from the perspective of an Oracle database - specifically how Oracle relies heavily on structured logs to give us the consistency guarantees that we have come to rely on. We can often apply this same pattern in our applications to mitigate some of the risks in working with an eventually consistent database. This requires a shift in how we think about our data. Developers think of “data” in terms of the public model that relational databases expose to us - a “column” and a “row”, but we just saw how Oracle operates with much more granularity. “Data” is a specific value at a specific point in time, and this definition of data is what allows Oracle to manage consistency. 

Pat Helland (who worked closely with Jim Gray and Andreas Reuter who gave us ACID) says it best in his paper “Immutability Changes Everything”:

The truth is the log. The database is a cache of a subset of the log. That cached subset happens to be the latest value of each record and index value from the log.

Let’s look back at the example financial scenario with this definition of data.

Consistency Remix

There are 2 things that bother me about my example. The first is that the entire thing is erased from existence if only the last step fails. The 2nd is that the 2 updates just change the balance without caring what the previous value was.

Problem #1 - Data vs Facts

The insert of the actual transfer record went just fine - at that point the transaction could be considered official but we have to wait for 2 denormalized tables to confirm the same changes. Relational databases are all about normalized data, but quite often when we talk about transactions we are really talking about dual writes of denormalized data. There isn’t any reason a single balance transfer needs to be written in 3 places other than to simplify the read model. It is one event that has multiple effects which we denormalize and write in a single transaction.

This is where the community is shifting its understanding of data. Facts are the source of truth, while data is the sum total of information that can be derived from the facts. To put it in context of our transaction - facts are the records in the redo logs, while the representation of those facts is the data tables. 

So what if the “log” in our application was the single insert of the money transfer? We’ll denormalize the view of that fact into the denormalized balance of Person A and Person B, but if one of those updates fails maybe it’s not right to totally invalidate the fact of the transfer or attempted transfer. If we can safely replay our log to ensure the balances are eventually updated then maybe ROLLBACK is the wrong model here - we could look to record our facts first and then ROLLFORWARD any denormalized downstream effects by replaying them until they succeed. 

You may be thinking “doesn’t this raise the possibility of inconsistent reads until the data is propagated”? Yes, but this is the same problem that relational databases face within an uncommitted transaction - which is handled internally using logs. Reads against the denormalized balance aren’t implicitly trusted, just as Oracle doesn’t trust their internal data files without a check against the undo logs. We can implement a similar pattern in our apps to control the consistency of our data and verify or adjust against the logs as needed. 

This isn’t a pattern I would want to implement everywhere, but in the few cases where transaction-like behavior is actually needed it provides a nice verification layer to ensure that all events have been processed. If you need to manage the potentially inconsistent reads of the log itself you can use a number of different tools from simple caching to lamport clocks or vector clocks. 

It’s up to us - if we have the source facts available in log tables we can project or suppress the publicly available view of that data however our context requires. On a related note see Martin Fowler’s Contextual Validation for some great thoughts about the validity of data and what we allow in the database. Perhaps the record of the attempted transfer is worth writing into our database regardless of whether it is ultimately valid or successful.

Problem #2 - Destructive Writes

We’ve talked a lot about the power of structured logs, and one of the central points is that they must be immutable or unchangeable. Once something has happened it is in the log for good… the only way to get rid of it is to write another log with a compensating action. This is a powerful concept that I’ve come to rely on so much that anytime I see an UPDATE or a DELETE statement I get uneasy. It feels so risky to me now to throw away critical data, yet we are so used to doing just that because ACID guarantees make it seem like a safe operation. Like most developers I have the scars to prove it isn’t safe at all. How many bugs or user errors have we seen where a record was updated or deleted incorrectly and trying to get it back is hard or impossible?

Just because Person A changes their address doesn’t invalidate the fact that they lived in another place before a certain date. Yet it is so ingrained in our old architectural minds that CRUD is normal and UPDATES and DELETES are necessary and harmless. They are fine for derived data, but I believe all critical source data should be modeled as immutable facts first. UPDATE and DELETE the effects of those facts all you want. In my example above I’m calling the balance a denormalized view of the data so an UPDATE could be ok but the statement still looks wrong to me.

Update balance of person A = A-$100

This statement is saying I don’t care what the balance was before, I’m sure it’s ok to just remove $100 from it. Again this seems like a risky behavior that we are used to only because ACID has allowed us to get away with it. Of course most applications would have a check to be sure the previous value was what we expected but this just adds complexity to work around this write after read data hazard. It would be much less error prone if our balance was always generated from the history of the logs/facts. The above statement is not idempotent - it can be executed once and only once. A balance update based on the sum of verified transactions can be done repeatedly and will auto-heal itself in the event something goes wrong. 

There are patterns for snapshotting so you don’t have to read every log from the beginning of time all the time, but this method of deriving denormalized data from source facts is so much safer than the alternative. I believe this strategy is critical if you have a distributed system - concurrent writes to an immutable log that feed into a single balance eliminate several complexities that are introduced by concurrent destructive writes directly to that field. 

Now that I’ve worked with Cassandra for a while and I have implemented these patterns I see that most of my initial fears about eventual consistency were rooted in anti-patterns that ACID had only let me get away with.

Any developer of multi-threaded applications knows the complexity and danger of shared, mutable state. This complexity is at the heart of ACID guarantees and we have been building applications on this foundation for years. If we lose the consistency guarantees we have to also move away from using the database as a container for shared, mutable state. 

What we really should be asking is “what other algorithms accomplish the same net effect?” I’ve found that the patterns to manage eventual consistency also make applications much more resilient, fault-tolerant and ultimately more consistent or correct. It is a complete fallacy that database consistency equals application consistency. Many of us including myself have believed this fallacy and relied on it on for too long… but I’ll write about that will be a separate post.

Wrap Up

Jonas Bonér says “Consistency is an island of safety, but so are immutability and idempotency”. I love this quote and have found it to be true - immutability and idempotency actually can give us back consistency in an inconsistent world. Decades-old principles still apply - structured log storage is not nearly a new concept. When trying to coordinate data or services that are distant or disconnected the tools of immutable logs and idempotent behaviors are invaluable.

It took me a while to wean myself off of reliance on ACID and I was very skeptical of all the voices that were critical of relational databases. The writings/talks of Pat Helland and Jonas Bonér in particular helped me reshape my thinking about what a database should do, and how to build an application around a database that couldn’t hide all the complexities of concurrency from me. With or without a relational database to rely on I would implement most of these concepts at least for any critical path in my application. Relying on the immutable logs of financial events that can be replayed over and over as needed enabled us to build an accurate, consistent and reliable system on top of an eventually consistent database. 

I’d highly recommend watching two great videos by these guys who explain it much better than I could:

Subjective Consistency - Pat Helland

Life Beyond the Illusion of the Present - Jonas Bonér

I think this article is also well worth reading:

Using logs to build a solid data infrastructure (or: why dual writes are a bad idea) - Martin Kleppmann

ACID.jpg

Back to the Future of ACID: Part 1

Back to the Future of ACID: Part 1


Borrowing from ACID Patterns to Tame Eventual Consistency

- Written by Matt Howard

Matt-Howard.jpg
 
Screen Shot 2018-07-21 at 9.30.16 AM.png

I recently had a discussion on a message board with someone who was looking for ways to implement ACID-like guarantees (Atomic, Consistent, Isolated, Durable) where using an ACID-compliant database wasn't possible. I think that conversation has a much broader appeal - I see the same general question being asked over and over in many different ways and in different contexts. It has more to do with a shift in thinking about data than it does with the details of database behavior. So I thought I’d move the topic over here for the benefit of anyone else who finds themselves in our shoes.

Developers who are used to building apps around traditional relational databases are struggling to adjust to some of the latest tools taking over cloud platforms. Several years ago I was trying to make sense of building a financial system on top of Cassandra - an eventually-consistent database. My question then, and the topic from this recent poster, was “how do I make things behave atomically and consistently without a database to guarantee it?” The example scenario was something like:

  1. Insert $100 transfer from person A to person B into a ledger
  2. Update balance of person A = balance-$100
  3. Update balance of person B = balance+$100

These things have to happen atomically - if any step fails the entire series must be aborted. This used to be something developers didn’t have to think about… wrap the statements in a transaction, send it off to the database and wipe our hands of the complexities that make it work. Now many are finding they have to figure it out for themselves with databases that have abandoned ACID in favor of speed and availability. So how do you maintain data consistency in a distributed or disconnected system? The answers I have found are:

  1. You can’t, stop trying… and
  2. Follow the patterns they used to implement ACID guarantees in the first place 

Unfortunately most of the answers you find online stop at #1… and leave the conversation at “consistency is overrated - you don’t need it”. While this is true in many circumstances there are critical times when it is necessary. The good news is that there is much more to the story. We’ve just become accustomed to doing things this way because we could get away with it - not necessarily because that is a good way or the only way of maintaining data. In most/many cases there are better alternatives that come right out of the ACID playbook.


Time Travel

To go forward with these new notions of consistency we have to go back a bit to remember how the old model works. This is a big topic that I'm going to distill down to two concepts that I believe make relational databases so reliable:

  1. Write-ahead-logs (WAL) - before you actually do something you log the fact that you are about to do it
  2. Idempotency - you can take the same action twice (by replaying the logs) without any unwanted side-effects… this is often defined without the word “unwanted” but that is a critical difference 

So let’s return to that atomic transaction above using Oracle as an example. I want to insert a record, then update 2 other records as a single all-or-nothing step. The first thing Oracle will do is generate REDO and UNDO logs before it touches my data. The REDO log is a description of the changes being applied so if the system crashes it can replay those logs to get back to a consistent state once it comes back up. The UNDO log is the opposite - a description of what the data was like before the change, so if the system crashes in the middle of a transaction it can then apply the UNDO logs to make it appear to me that a partial change never happened. UNDO logs are also used to effectively hide uncommitted transactions from concurrent connections.

  1. Insert $100 transfer from person A to B into ledger
  2. Update balance of person A = -$100
  3. Crash / failure / whatever you like

Since we didn’t commit the transaction Oracle will apply our undo logs on recovery to clean up the $100 ledger entry and the $100 debit to person A’s balance.

Note that atomicity is a bit of an illusion. “All-or-nothing” is a display trick that the database does to make it look like nothing happened. From https://docs.oracle.com/cd/B28359_01/server.111/b28310/undo001.htm:

When a ROLLBACK statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction.

The changes “were made” for steps 1 and 2 above. It’s just that Oracle’s read model uses the undo log to hide those changes from other concurrent sessions and it takes compensating action to remove the unwanted effects of those changes in the event something goes wrong.

The same UNDO logs are used to control the consistency of reads for data that is either in the middle of being changed (but not committed) or has been committed but only after a read request was issued.

ACID Part 1 image.jpg

http://docs.oracle.com/cd/E11882_01/server.112/e40540/consist.htm#BABFDBAJ

The above diagram shows how Oracle hides updates to 2 blocks of data that were committed at time SCN 10024 from an earlier SELECT statement issued at time SCN 10023. It reads the 2 blocks from SCN 10024, sees they are newer than the requested “date” and applies the UNDO logs which revert those 2 blocks of data back to SCN 10006 and SCN 10021.

Note that if you don't fully control the read model then you also lose control over your consistency boundary.

This is a key tenet of micro services that pays off greatly when trying to manage eventual consistency - control your read model by not allowing outside actors to peer into your internal state.

Developers are so used to things appearing as if they never happened on rollback that we make it an absolute requirement, however by adjusting our definition of “never happened” to match Oracle’s definition we gain a lot of flexibility to work in a world of relaxed consistency. We certainly often write details of attempted transactions to our application logs and don't expect a database rollback to erase those logs because application logs aren’t visible to the users. In fact we like to keep those logs so we know something was attempted. The existence of “invalid” data isn't an issue if the application doesn't expose the incorrect effects of that data. Relying on structured logs is a decades-old pattern in computing, and many argue it is rooted in practices dating back millennia. Replaying time-series logs to reconstruct a view of the world is almost inherently idempotent and gives us back much of the consistency control developers are seeking. In Part 2 we’ll look further at what this means and how adjusting our definition of “data” can help us to apply these concepts in our own applications.

Have an Opinion – Part 3

Have an Opinion – Part 3


Axispoint-Blog-Opinion-3.png

Written by Travis R. Rogers, Director of Software Engineering for Axispoint

This is part three of a 3-part series about the art of the opinion. Have an Opinion – Part 1 provides some definition and justification for this method and Have an Opinion – Part 2 provides a basic set of rules for having an opinion. Opiners, those that have and willingly express opinions, are a special breed and require understanding of their nature in order to expose optimal value so this article discusses some of those traits.

I encourage you to read all of Part 1 and Part 2 but in case you are just interested in the psyche of opiners, I have copied some particularly relevant caveats and provisos into this article.

Truth: There are six different English definitions of Opinion provided by the online Oxford Dictionary. From those, the definition this article refers to is, 
 

“A view or judgment formed about something, not necessarily based on fact or knowledge.”


That’s right, we accept and even expect that people will present opinions “…not necessarily based on fact or knowledge” because having an opinion is a process as well as a destination.

Truth: Opinions, in our world, include ideas, thoughts, points of view and etc. They will all be treated the same.

Truth: To those that know me, some of the rules or guidelines presented in this series will smell strongly of hypocrisy. Admittedly, I struggle to follow the rules but that doesn’t make the rules less valid, it just provides additional (or at least some) evidence that I am human.
 

What to Expect from Opiners

1. Lots of Opinions.

Obvious…but here goes. If you tell people their voice is important, encourage them to use it and hire people because they have an opinion you will be surrounded by opinions about every possible aspect of existence. Oddly enough, prior to Clinton’s famous comment “It depends upon what the meaning of the word ‘is’ is.” I had multiple opportunities to engage in a debate about the definition of “is”. 

Most of the time I enjoy a plethora of opinions but not everyone does, even incessant opiners. On the plus side, there is rarely a time when you go to lunch and everyone says, “I don’t care whatever you want.”

2. Lots of Creativity.

I was looking for synonyms to Opinionated and was a little surprised by the large amount of seemingly negative and close-minded words like biased, inflexible and intransigent. If it hasn’t been made clear in prior articles, in the Axispoint culture having an opinion is different than these negative connotations. A group of people that have an opinion and are able to follow the basic rules of having an opinion (see Part 2) are ultimately very creative and open to other’s creativity.

3. Lots of Questions.

Well, it is one of the rules and also a common trait of technologists.

4. Lots of Truth.

See rule #3 and #4 above. If you ask a question, someone will answer it honestly. Years of experience have led me to adopt a personal guideline, “Don’t ask a question you don’t want to really hear the answer to!” Several years ago I was on vacation and had my hair buzzed because it was hot. When I returned to work I asked someone what they thought of my hair. Their answer, “It’s brutal.” It was the truth…not tactfully put…but the truth. Would I have felt better if they had said something like, “It’s not my favorite for the shape of your face.” Or, “I preferred your hair the way it was before you left for vacation.” Maybe, at least for a few minutes until I deciphered the code.

5. Lots of Confidence.

Some might say, “Lot’s of Arrogance.” Having an opinion is not arrogant in and of itself, but arrogance is a byproduct of not properly assessing the value of an opinion (see rule #1). Confidence is good and is expected when people have their opinions poked, prodded and beaten by equally confident and competent people.

6. Lots of Fun.

Good people interacting to create great solutions is just fun. With the right people and attitude, the environment builds respect and camaraderie and provides opportunities for people to learn, contribute and flourish in ways not available elsewhere. On top of that, who doesn’t love a good debate?

HaveAnOpinion_01.jpg

Have an Opinion - Part 2

Have an Opinion - Part 2


Axispoint-Blog-Opinion-2.png

The Golden Rule

Written by Travis R. Rogers, Director of Software Engineering for Axispoint

This is the second part of a 3-part series about the art of the opinion. Have and Opinion – Part 1 provides some definition and justification for this method while this article provides a basic set of rules for having an opinion. I encourage you to read all of Part 1 but in case you are just interested in the rules I have copied some particularly relevant caveats and provisos into this article.

Truth: There are 6 different English definitions of Opinion provided by the online Oxford Dictionary.  From those, the definition this article refers to is,

“A view or judgment formed about something, not necessarily based on fact or knowledge.”

That’s right, we accept and even expect that people will present opinions “…not necessarily based on fact or knowledge” because having an opinion is a process as well as a destination.

Truth: Opinions, in our world, include ideas, thoughts, points of view and etc. They will all be treated the same.

Truth: To those that know me, some of the rules or guidelines presented in this series will smell strongly of hypocrisy. Admittedly, I struggle to follow the rules but that doesn’t make the rules less valid, it just provides additional (or at least some) evidence that I am human.

The Golden Rule

If you think you know the answer, then say it!

Let me set the stage:

1. A problem presents itself.

2. A meeting is held to discuss the problem.

3. A decision is made.

4. Investment is made towards that decision.

5. A person that participated in the meeting says, “You know, when we were discussing this the other day I thought that…” and out of their mouth comes something they didn’t previously present which turns out to be:

a. An important point that would have changed the decision.

b. Or a better solution to the problem.

c. Etc.

Having an opinion, especially one that is firmly held, and not speaking it in a timely manner is highly frowned upon. This is sometimes referred to as “the biggest sin” within our design process.

The Rest of the Rules

Having and opinion could be considered a form of brainstorming but it’s more than just spouting out whatever is on the top of your mind and some basic expectations need to be understood and managed in order to get the most value.

1. You must be able to honestly assess the value of your own opinion.
This rule allows for the creativity of traditional brainstorming via the portion of the definition that says “..not necessarily based on fact or knowledge.” But, it requires honesty. If you have an opinion that is purely based on gut feel or just an idea that you want to put out there then fire away, but preface it with that information. This way everyone is clear on how to approach the opinion. For example:

Bob: “I strongly believe that we should do X.”

Jan: “Three months ago I worked on a project that had this same set of circumstances. We were unsure what to do so we tested X, Y and Z. Z was the best option because it achieved the goal with the lowest effort.”

Jon: “I have an idea that hasn’t been mentioned but I don’t really have any experience with it, what do you think of F?”

Ann: “I don’t have this specific experience but 20 years of doing this type of work leads me to believe that Y is the best option for these 3 reasons…”

Bob is highly respected and very capable but we initially have no way of knowing how he came to his opinion and how valuable it is therefore it will be challenged (as will/should all the opinions above). As it turns out, it was just an opinion with no facts or specific knowledge to back it up. It also turns out that upon being challenged Bob asked Jan for more detail about her experience, the group identified an inconsistency between the current problem and Jan’s problem of which Jan was not aware. It was eventually decided that X was actually the right path forward for various reasons, the very least of which was Bob’s initial comment.

2. You must be able to properly express your opinion.
This is a very simple set of guidelines, but are probably the hardest to maintain. The first is to be nice.  Don’t raise your voice. Don’t call names (passively or directly). Don’t pound on tables or white boards. Don’t pull rank to shut people up. Don’t talk over others. Etc. ad nauseum.

The second is to be forgiving. Stating an opinion that you know will be challenged by people whose respect you desire is a significant personal risk and eventually someone will raise their voice and/or etc and, within bounds, each of us should be allowed a pass.

3. You must be able to listen to other’s opinions.
Stop reading email. Stop looking at your phone. Stop thinking of your next argument and listen. Listen not for why someone else is wrong but for what they are right about and why they think they have a point. Actively search for the value that is inevitably there. It is each persons responsibility during these conversations to find and piece together the bits of genius.

If you are unable to listen mentally for some reason (bullheadedness?) then give yourself some time away from the meeting to reflect on what you heard and then search for the value. This is critically important and often difficult for myself and others of my opinionated ilk so I often refuse to finalize a decision at a first meeting instead we “sleep on it”. Not only does this provide separation from the stresses of the conversation but also allows the subconscious to process everything that was said. Uncountable times I have walked from a meeting thinking someone was absolutely wrong only to realize later that there was a little bit (or a lot) of genius in the opinion that I had mentally and emotionally blocked.

4. You must be able to listen to other’s opinions about your opinion.
If you give an opinion in a room full of opinionated people, you will be challenged. Gird yourself and then refer back to #2 and #3.

5. You must be able to solicit opinions from others.
A key indicator that someone is not listening is when they are not asking questions. Ask questions, present scenarios, draw diagrams, act things out…whatever. All this in an effort to get information from others instead of making your point. You are not the smartest person in the room and even if you are, someone else in the room has thought of something you haven’t.

6. You must have the ability to change your mind.
It’s that simple, if you can’t change your mind then you don’t have an opinion. You have a fact in your head, in the realm of “The earth is the center of the universe and if you say otherwise then you’ll be placed on house arrest forever.”

It is ok, to present and defend your opinion with confidence and vigor but once you reach the point you believe you are absolutely right about a complex plan/topic then you are failing the group and wasting everyone’s time.


7. You must have the ability to accept a path forward that does not coincide with your opinion.
Debate and discussion cannot go on forever and consensus may never be reached or be valuable. Someone will eventually say “I heard and understood and this is the way we are going” and that way won’t always match your opinion. Simply put, that hurts, but it is a waste of time and energy to constantly rehash old battles or say “I told you so”. This sabotages the process of future problem solving, wastes time and is generally petty. If you want to have a voice than you have to learn to maturely deal with the emotional ding of not getting your way.

8. You must be able to engage in positive verbal conflict.
Open debate or conversation is a form of conflict but it doesn’t have to be negative. Maybe this is a restatement of several rules above but it is worth saying. Negative people have valid and valuable opinions. Negative events (discussions and etc.) might identify valuable plans/solutions, but negative conflict has a limited life. Positive conflict can perpetuate and get better. Conflict is inevitable and always has some value. Positive conflict is invaluable.

9. You must be able to walk away.
If you like being heard and like solving problems most of the time you will walk away from presenting your opinion invigorated and excited even if you didn’t get exactly your way. Regardless of how stubborn I am, if my opinion provides no value but someone else or a group finds an elegant solution to a problem I am elated. But there will be times when you are hurt a little by the process. When that happens…compartmentalize, apply the Vegas principle or whatever but leave it at the door. Remember that these are your friends and colleagues which you spend a large amount of time with and work is fun when you get along…one conversation is not worth a lost friendship.

10. You must be able to apologize.
Recently, I had an opinion about the way something was done and I let it fly. A while later I realized that I had not read something correctly and also had broken several of the rules above (especially #2).  Unfortunately, I had emailed my opinion and cc’d people so of course I had to email an apology and include with all the same people…that’s only fair. If you want a voice it will not always make you proud so be prepared to use that same voice to make amends within the same context and grandiosity as you err.

Summary

The biggest sin is having an idea/opinion/answer and not speaking out but there are a few other rules that keep an opinionated environment from becoming chaos. The 1st segment of this series discuss the virtues of nurturing opinions and the last describes some of they key traits of people that thrive when they opine.

Have an Opinion – Part 1

Have an Opinion – Part 1


Axispoint-Blog-Opinion-1.png

Written by Travis R. Rogers, Director of Software Engineering for Axispoint

Spend a little time around Axispoint and eventually you’ll hear someone extoll the virtues of “having an opinion”. Having an opinion is required in order to facilitate how we work, this is the first of 3 articles that define what we mean and discusses many of the related dynamics. Part 1 will begin the definition and provide some reasons that this technique is valuable.

Future articles separate from this series will provide specifics on how having an opinion facilitates other parts of our work style and environment (i.e. “Design is a Contact Sport” and “Design is a (benevolent?) Dictatorship”).

Truth: The “someone” mentioned above is often me, which might just be a way to justify my actions. Regardless, having an opinion has long been valued within Axispoint and although pervasive and perpetual; until recently, was more subconscious than manifest. Illogical…I know. This cultural practice, intentional or otherwise, is part of the Axispoint psyche and those with the courage to be heard, have a tendency to thrive. 

Truth: Not everyone considers having an opinion worthwhile and some will argue that the negatives (and there are negatives) outweigh any perceived benefits. I find this concept amusing since having an opinion about the relative value of having an opinion requires that the opinion about opinions is valuable.

Truth: There are 6 different English definitions of Opinion provided by the online Oxford Dictionary. From those, the definition this article refers to is, 
 

“A view or judgment formed about something, not necessarily based on fact or knowledge.”


That’s right, we accept and even expect that people will present opinions “…not necessarily based on fact or knowledge” because having an opinion is a process as well as a destination.

Truth: Opinions, in our world, include ideas, thoughts, points of view and etc. They will all be treated the same.

Truth: To those that know me, some of the rules or guidelines presented in this series will smell strongly of hypocrisy. Admittedly, I struggle to follow the rules but that doesn’t make the rules less valid, it just provides additional (or at least some) evidence that I am human.

Why?

Being surrounded by a bunch of opinionated people that are encouraged to bloviate, sounds like a big hairy free-for-all. That normally doesn’t transpire since traits like respect, honesty, capability and thick skin tend to minimize the anarchy. There is a cost in time, effort and patience that come along with this style but for us, the benefits far outweigh the costs.

1. Training, Education, Experience.

We are consultants and our clients expect us to express opinions defined as:

“A formal statement of advice by an expert on a professional matter.”

Providing well structured, fully thought out and tactfully stated opinions require training and practice. Seeing the way others think and approach solving problems expands each individual’s thought processes and makes us all more aware, respectful and thorough. The world is full of rough edges and stressful situations so having a safer environment to discover which personal and group strategies provide control and positive outcomes prepares people for providing the proper types of input and guidance when dealing directly with our clients. By hearing and understanding other opinions and having to reconcile them with our own, we learn how to listen, ask questions and ultimately understand each other and our clients better.

2. More Options (or Exponential Bits of Genius).

Our clients have imposing barriers that need addressed whether it be time, money, technology, complex dependencies, politics or all of the above. The combination of barriers and their specifics vary by client/project. Plus, clients generally know their domain better than us and have their own highly capable people addressing the issue. So how is it possible that Axispoint provides our clients the necessary leverage to dispel these barriers? There are several reasons but the one relevant to this topic is “Exponential bits of Genius”.

For various reasons it is common that in a group of a several people there is one or maybe two that dominate the process of identifying a solution. Simple math quickly shows the fault in that process. Let’s say there is a a group of 6 people discussing a sticky problem. If each person has 2 uniquely valuable ideas and one person dominates then you get 2 ideas but if everyone contributes, then you get 12 ideas or 600% more ideas. 

600% more ideas sound pretty good, but in the right environment, where multiple people are empowered and capable of contributing, the difference is much greater because each idea has the possibility of reacting with every other idea to make a new uniquely valuable idea. Back to our example, the math is 2^6 or 64 options which is 3200% more bits of genius!

Yeah, I know this is human activity and the result will not really be linear to the number of people/ideas, but the point is still valid. A few opinionated people with a broad cross-section of capabilities and experience working together will provide significantly more options.

3. More Complete Solutions.

It is rare that a single person can think of the best idea and consider all the risks and nuances in any complex problem. It is common however, that different people will focus on different aspects of the same plan, or that they advocate a different plan because of specific risks or challenges obvious to them. Ultimately when multiple people offer various opinions, some way forward has to be selected and will favor some opinions over others. By taking the time to understand the supporting reasons (whether logic or experience) for each opinion, adjustments can be made to optimize the benefit behind some ideas and minimize the risks behind others even when these opinions aren’t primary to the vision driving the plan.

4. Coverage.

It is literally impossible for one person to keep up with the state of all computer technology. Axispoint builds custom software and we approach our projects from a standpoint of being technology agnostic. While we have favorite technologies and techniques that influence us, our agnosticism guarantees that we won’t reject a technology out of hand because it’s not our preferred or most understood path. It is common that prior to our involvement our clients have been advised that they need to scrap existing work and rebuild it using “X”. We believe the primary reason to support a recommendation like this often boils down to the familiarity or expertise a particular vendor/person has with “X” technology. Internally we refer to this as being their hammer as in the adage, “If your only tool is a hammer then every problem looks like a nail”. Unfortunately, what is really happening in some circumstances is that the problem is clearly not a nail and rather than find or learn a more proper tool, the problem is replaced with a nail so that the hammering can commence.

By fostering an environment where people are capable of expressing their opinion, we don’t have to rely on one or two people to keep up with technology. Instead we spread the load which makes for wider and deeper coverage and is easy for Axispoint to bring proper solutions to bear effectively.

5. Consistency.

Our clients typically want our help implementing some manner of differentiation and advantage based on innovation. Additionally, every project has multiple potential paths to success. In fact, some of our projects that appear the same have successfully and properly followed dramatically different paths. There is one thing that every client expects from us on every project…efficiency. A key method of achieving efficiency, is through consistency or

“The quality of achieving a level of performance which does not vary greatly in quality over time.”

Opinionated vocal people, different project/client constraints, technology agnostic, custom software…it sounds a little like a recipe for madness and that efficiency through consistency is unlikely. Admittedly there is no single formula that anyone can possibly apply in the described circumstances. Regardless, Axispoint achieves consistency along with the resultant benefits through a variety of mechanisms and patterns that are empowered by our combined capacity to have an opinion. People at Axispoint at all levels use their voice to identify and leverage patterns that are appropriate to the circumstances. These could be technology patterns, process patterns or some combination, they could be patterns we have learned internally or externally and they can vary in scale from micro-patterns to patterns that almost reach formulaic project solutions. An example of a tried and true pattern that is used in many of our projects is our Hybrid Offshore model.

6. Other.

In a nod towards brevity I will list additional benefits of cultivating opinions and for the moment leave most of the detail to the imagination of the reader.

  1. Good Mental Exercise.
  2. You have one anyway, might as well voice it.
  3. Prepare to Innovate.
    1. Every innovation begins with the phrase “I believe” and the understanding that there is risk in acting on that belief.
  4. Garner Support.
    “…I am obliged to say to the American [technologist], ‘This is why you ought to do this’ and then [s]he does it.” 
    1. There is a quote from Prussian General Friedrich Wilhelm von Steubon who helped train George Washington’s troops during the revolutionary war. The quote itself targets American’s but it seems to fit most technologists of today and I think it is relevant,
  5. In our business, if you can’t explain the “Why” of something it is hard to gain support.
  6. Validate future and on-going plans.
  7. Being Involved and Heard is Fulfilling.
HaveAnOpinion_01.jpg

From House To Hotel – A Guide to Successful Scaling Code Organization

From House To Hotel – A Guide to Successful Scaling Code Organization


Axispoint-Blog-Scalability.png

How should code be organized in an enterprise application?

By Mike Trzcianowski

Imagine you're a general contractor who has been hired to install a new fridge with an ice-maker at a single-family house.

Just from the outside, you notice that the house is a little strange. All the doors and windows seem to be on one corner of the house. You walk in and notice that the first room has 10 ceiling lights, 15 light switches on the wall and 30 electrical outlets, but otherwise it's empty. The room next to it has 4 sinks, 2 toilet bowls, 1 shower, a garden hose, etc. Another room is full of furniture with beds, sofas, chairs, desks and tables. 

You scratch your head and wonder. Where do you put the fridge? How do you connect the fridge to the outlet in one room and to the water pipe or sink in the other room?

This example illustrates the situation I usually encounter when I start working on an existing code base. The developers have organized the code and assembled in terms of data layer, business layer and UI. It's great, isn’t it?

Now, imagine you scale the same problem from a house to a hotel. You have 200 sinks in one room and 500 light switches in another room. The electrician is installing a new A/C unit but, well, his time is limited, so he hooks it up to the first electrical outlet he finds in the "electrical stuff" room. Then he runs a drainpipe to the first pipe in the "plumbing stuff" room. When he turns the A/C unit on it's a disaster.

Why do software developers do this? There are multiple reasons why this happens. Some of them are:

Reason 1: It’s easy to do organize code into layers but more difficult to organize by function.

A reasonably well-written class can be easily classified as data, business or UI layer. On the other hand, the same class could be used by multiple components and in such case it is more difficult to decide whether it belongs in one, the other, or maybe on its own. In other words, it’s easier to decide whether a piece of code belongs in one of three or four layer buckets, than in an undetermined number of feature buckets.

Reason 2: Developers assume that layer organization is equivalent to project or assembly organization.

That is not usually the case. In web projects, your UI might be a web page, whereas the business logic might be inside of a web service. However, the web service will usually include business and data logic. In 99.9% of the times, you don’t need a separate data layer assembly because you will not be supporting multiple interchangeable databases.

Reason 3: Most code examples and project templates are for simple projects. 

When starting a new project, you might see some folders created automatically for you, such as Controllers, Views, Repositories, etc. This may be sufficient for a small project or component, however, once you start adding multiple features, the basic structure no longer works because you have everything intermingled.

So, how should code be organized in an enterprise application?

Rule 1: Organize by feature and not by layer. 

Imagine you are adding a new shipping feature to an order processing system. If everything is organized by layer, you have to dig through the different classes and decide what you need from the data and business layers. On the other hand, if you organize by feature, you can easily find all the classes for managing orders and products in their respective areas.

The additional benefit, especially in an enterprise system, is that it’s easier for different components to have separate databases or even storage mechanisms. This is important because you can now distribute, scale, or test specific parts of the application without having to deploy the full application.

Rule 2: Separate layers by namespace and not by project or assembly.

It’s much easier and more efficient to deploy a single assembly that includes all the components for a feature, while deploying multiple layer assemblies when you really use only a subset of each. Use assemblies only when the code in each assembly is deployed independently.

Rule 3: Keep it agile. Keep refactoring.

Don’t overthink the organization. You may still begin with a single component with layers separate into folders or namespaces. But as you add different features to your application, you will need to rethink how the code is evolving. Don’t just throw new code into the layer folder. The same principles you apply to a class may be applied to a component. Encapsulate logic that relate to the component and push unrelated logic into separate components or namespaces — just think of the single-responsibility principle, but at a higher level.

In summary, what works well for a simple app, may get you in trouble with an enterprise solution. It’s easy to get complacent and not touch existing code. But that is a trap. You need to rethink the evolution of the application structure as you add more and more components. Having the code organized into layers is better than no organization at all. 

However, this isn’t enough for an enterprise application where components need to be reusable for different areas. Plus, don’t forget to think about the work involved in maintaining the application in the future. It takes effort to come up with a good organization for the code. The time spent now will pay dividends in the future. It’s a lot more difficult to come back to legacy code and figure out how all the classes are related to each other. Instead, organize the code as it is added and provide a visible structure that can be easily seen later without having to dig deep through the code.

Comment below to let us know your thoughts on successful code scaling and to find out more about our software development capabilities.

References and related articles:
“Features and Components” - http://scaledagileframework.com/features-components/
“Mapping software architecture to code” -http://www.codingthearchitecture.com/2013/04/08/mapping_software_architecture_to_code.html
“Package by Feature, not layer” - http://www.javapractices.com/topic/TopicAction.do?Id=205
“Scalable code organization in AngularJS” - https://medium.com/opinionated-angularjs/scalable-code-organization-in-angularjs-9f01b594bf06“Single Responsibility Principle” - https://en.wikipedia.org/wiki/Single_responsibility_principle

housetohotel.jpg

Commercial Real Estate Success Story

Commercial Real Estate Success Story


Axispoint-Blog-Commercial-Real-Esate.png

Implementing a more productive work environment that minimizes costs and maximizes efficiencies.

1. Business Challenges

A leading commercial real estate broker and property owner serving multinational corporations, major space users, developers, owners, institutions, lenders and investors throughout the Tri-State area was hampered by out-of-date technology architecture and manual accounting procedures. They were in need of a real-time online operational and financial accounting system that could be integrated with a broker performance system in an effort to create more efficient business processes and workflow.

Business Challenges Overview:
• Unable to find an off-the-shelf software product that could account for the sophisticated and complex revenue process associated with highly customized commercial real estate transactions
• Legacy accounting processes were outdated and inefficient
• Financial reporting and commission calculations were delayed due to manual processes

2. Axispoint Solution

Axispoint business analysts consulted to fully understand the complex nature of commercial
real estate transactions, and the challenges associated with properly accounting for them efficiently. While there are several vendors that offer general accounting software, none offer a product designed specifically for accounting for complex real estate transactions from both an operational and financial point of view. Armed with both industry knowledge and technical
expertise, Axispoint architected and designed a complete system comprised of custom written and off the shelf software.

Axispoint customized the Microsoft Dynamics platform and developed an integrated custom .NET application to handle the complex broker commission rules. The application automates the entire real estate accounting process, calculates complex broker commissions, and generates the corresponding accounting entries that accompany each transaction. The system serves as a comprehensive and dynamic database that maintains the brokers, clients, deals, and properties that comprise the portfolio.

Axispoint Solution Overview:
• Architected an enterprise broker performance and financial accounting system comprised of both proprietary and off the shelf software
• Delivered a highly organized application that lists all brokers and properties, calculates appropriate broker commissions, and generates the corresponding accounting entries
associated with each real estate transaction

3. Business Value

Axispoint helped identify, map, and redesign critical finance processes, which brought a new level of sophistication to the entire organization. With the implementation of the system, the company can process accounting transactions and calculate commissions faster. Brokers can execute more business and serve their clients more effectively, and efficiently. The technology substantially reduces the effort and time required to properly account for deals and to collect receivables than the manual entry accounting system previously in place. The updated technology platform serves as a powerful recruiting tool for the company, illustrating the commitment to IT to both clients and prospective employees.

In addition to providing a more productive work environment, the system minimizes costs, since personnel increases are only associated with the demands of higher deal volume.

Business Value Overview:
• Business process redesign brings a new level of sophistication and efficiency to the organization
• Improves processing and calculating of commissions while reporting operational and financial information in a timely manner
• Provides brokers and the finance department a clearer vision of outstanding client invoices
• Allows the company to serve clients quicker, offering better quality of service and enhanced communication
• Improves the firm’s cash flow collections process
• State of the art system is a boon to recruiting brokers and clients