This is a continuation from the previous post:
Applications that allow user defined scripts to be run along with a rich suite of scriptable objects and APIs arguably improve automation. For over two decades with varying technologies, Microsoft has shown an example of improving script ability and automations. First there was Component Object Model, then it was Visual Basic that could use those objects and finally, there was Powershell. Many applications, services and instances can allow extensibility via user defined scripts. These can be invoked from command line as well as from other scripts. It also helps with testing.
Lastly, the importance of customer feedback cannot be understated in customer facing clients such as mobile applications and designer interfaces. Usability engineering can make it more convenient to navigate pages, use controls and view dashboards but the customers dictate the workflow. The prioritization of software features via customer feedback rests primarily with the product management team not the engineering team.
The set of considerations mentioned so far have been technological. The discussion that follows adds some more based on the business domain. Decades of efforts in streamlining data access layer across business domains have given rise to expertise and maturity in web architectures. Yet businesses continue to develop home grown stacks for their respective business applications, some under the requirement for adoption of container orchestration technologies and others with the excuse of developing independently testable microservices. Companies such as finance are heavily invested in shared data and indexes. They have a need for extract-transform-load as core part of their services. Retail companies such as for clothes or beverage are increasingly invested in point-of-sales experience. Telecommunication companies are required by law to meet compliance both for subscriber records as well as anti-trust regulatory compliance. Due to their different requirements, these organizations come up with a portfolio of solutions and then retrofit standardization and consistency across their applications and specially when technical debt mitigation is permitted. All the mentions made so far have proven useful across industries regardless of their choices of a technology such as what authentication to support. Therefore, customization and business domain requirements should not be allowed to circumvent or ignore the mentions made here.
Certain improvements are driven by their business priority and severity. Even if the technology and architecture is determined up front, their implementations may take shape differently from the others. Even the end state of the implementation at the time of release may not be at par with what was on the whiteboard once, but the techniques suggested here have stood the test of time and landscape. Perhaps the single most important contributor for these has been the popularity of their usages with developer community. For example, this is demonstrated by the adoption of GraphQL/REST over SOAP and containers over virtual machines. Developers also find the public cloud architecture convenient for the v1 products of many companies in several sectors and verticals. Developer community forums have also been a significant source of information for this document.
The following section is a note about testing. Mobile applications are written with the help of simulators that have internet access. It is common for the developer to test the user interface as and when it is being developed. Automations for the mobile applications are rather cumbersome. One of the ways to mitigate this difficulty has been to separate the front-end testing with a mobile view that can be called from desktop browsers. Usually, the web interface displayed from a backend is in response to a web request that can take additional query parameters to request a response for the mobile platform. Then there is browser driven user interface automation that can even work headless and drive through the workflows using the web controls. A combination of such approach can thoroughly test the mobile application from a users' point of view.
Lastly, standard practice for web applications via enterprise application blocks or cloud computing documentations is a great place for reference and resources but we must take note that the spirit with which they are written, suggests that our implementations can be lean and mean so that we may incur less total cost of ownership in development and operations.
No comments:
Post a Comment