Showing posts with label Technical Writing. Show all posts
Showing posts with label Technical Writing. Show all posts

Wednesday, December 13, 2017

Service Level Agreement for Cloud Computing setup

SLA for Cloud Computing Service Provider
As a standard practice,  the customer and service provider enters into a service based agreement before commencing of any project. The agreement is a way to determine and note down the requirement from the customer, commitment by the vendor, and pricing for the entire project. The Service Level Agreement (SLA) in case of cloud migration from traditional infrastructure includes cloud carrier, provider, broker, and list of services required to make the upcoming solution operable.
Besides, the SLA mentions the model (Iaas, Saas, or Paas), method, and ETA from start to complete the migration.
The SLA is a legal entity and involves the law. Although, practically, SLAs are only for the formality and both sides keep enough room to manage extra requirements and additional time taken to develop the system. But, in case if the matter reaches the court of law, the SLA helps. In case of any organization, the SLA is not just a legal document; it also states the details of the entire project as the federal system seeks.

Method

A core SLA team initiated the SLA. This team consists of experts from the organization. The idea is to recognize the focal point of creating an interface with the service vendor on SLA.
Once the team is set up, and visions are straight the team chalks out the main agreement points. The experts who write the terms and conditions in the form of bullets ensure that they write down every single detail concisely. A very well written SLA forms the base of a trustworthy relationship between the vendor and service provider.
In case of any organization, moving its structure from traditional to cloud-based model like Iaas, multiple things must be part of SLA. Non-disclosure commitment of the data, adherence, and compliance with the government policies about the information handling, service commitment, output expectations, storage plans, backup plans, and total control on the system from access to destroyable rights are few of the points must be added to the SLA.
First of all, there has to be a Single Point of Contact (SPOC) from the organization to Cloud vendor. The SPOC helps to clear any chances of communication gaps. A vendor cannot say that they had informed about a possible downtime unless they write to the SPOC.
During the entire development process, the vendor should be asked to share the report of key functionaries, test cases, expected test results, and achieved results. Deviation beyond a certain level must be considered as a breach of the SLA.

Discussion

An SLA is shared in electronic form for review between both the parties must be on physical, and court notified paper. Each of the terms must be read, understood, and committed by both the parties.

Conclusion


When there are many small and large services being worked upon, an SLA becomes an important document. It has to be abided by both the parties for a smooth transition ad business operation.
Photo on Visualhunt.com

Thursday, November 30, 2017

What is the best method to set up a Cloud?


Setting up a cloud infrastructure is not the issues, the only thing needs attention is the proper usage of all the services. For this, one needs to start from the Proof of Concept stage and then move towards the sustainable, stable application. The only step that you can omit from the software development lifecycle (SDLC) is the requirement gathering. This is so because the department knows the requirement.

The objective is to transform the entire system from legacy and distributed platform to unified cloud computing. In this endeavor, the first need is to determine the method to set the cloud up. The process entails a big deal of risk. After all, it’s not like changing the curtains of the window, and it needs a careful shift.

Among several methods available, the In-house development and deployment is the most appropriate in the view of safety and security of the information exposed to the development team. The in-house team can be restricted and controlled much easier than a set of people working remotely at a vendor’s premises.

The foremost thing about using an in-house development setup is that the existing subject matter experts can be used to write down requirements and test cases. There is no need to spend weeks in chalking out the plans and priorities.

The people who are already part of Department know well what information can be revealed to the developers and what details should be masked.

When the environment is all set, the new cloud computing programmers, database experts, network engineers, and technical writers can be hired. Each of the newcomers can be assigned specific roles under the supervision of existing experts. These existing experts may not be aware of choosing the best model or great programming framework, but of course, they would be aware of expected output quality.
The most important reason why the in-house development is preferred over an outsourcing paradigm is the security. The new developers can be made to sign the non-disclosure agreement. Apart from this, their computers can be blocked with the internet until the programs are ready. Restrictions on bringing storage media or phones can be controlled so that the chances of information leakage go out of the scene.

In-house development ensures the security of work. It also ascertains that the development is going on the right track and everything is being tested as per set standards. Developers and others have clarity of task and experts know what to expect. This way the client and vendor both work in the same cubicle, thus there is no scope of deviation from the expected results. Department of Defence manages sensitive information, and this is why the in-house development method will be appropriate.

In-house development and deployment is dependent on internal skills and availability of in-house resources to develop new services. In-house development and implementation should reduce the learning curve on how to link to legacy services. With In-house development and implementation, the enterprise owns the cloud service and can add updates on the enterprise timetable. In-house development and deployment offers potentially tighter controls during the testing process. In-house, test managers can work closely with other IT and business leaders to ensure complete testing is done.

Saturday, November 25, 2017

Infrastructure as a Service

Introduction
Cloud Computing provides a conducive environment for all kind of computational requirements. In case of a company with sensitive data, the requirement is to have an infrastructure highly secure besides all the computational capabilities. Among three Cloud Computing models, the most robust one is Infrastructure as a Service (Iaas) and that will be most appropriate to meet all the requirements.
Infrastructure as a Service also known as IaaS, provides storage, networking, processing, and other basic and advanced computational capabilities. The capabilities include server management and operating system management. The company personnel will not need to manage any cloud infrastructure but they can manage the deployment of applications which will help them keep a total control.
Methods
            The implementation methods are not straightforward. It needs carefully analyzed data and understanding of the impact of transformation from legacy to cloud-based computing. Analysis needs to be done on the Total Cost of Ownership (TCO) and Return on Investment (RoI). In case of a software company, the TCO should not be a major concern but yes, the returns like the ease of access, robust setup, and strongest firewall which is non-penetrable will be some of the key things to consider.
Once the expectancy is set, the program will move and analyze whether putting all the sensitive data on a cloud which is owned by someone else and is being run at a remote location is good or not. This concern can be easily quashed as the data storage is done on top of encryption-based algorithms. Even the owner of the data who has deployed it cannot read it without the appropriate code that has token and secret keys embedded.

The implementation shall begin by writing a small piece of program for the cloud setup. This program can be a small application like allowing employees to get authenticated through a login interface. Besides deployment of the database at the backend, the company can put all the validations in a place like a number of invalid attempts against an ID and then a log generation to check which account was attempted by an intruder. This attempt may be informed as a security breach to the concerned officer and the closest available agent may check the location right at the moment to avoid any escape attempt. 
This single application can be used to test, in-house authentication as well as remote login. While the services are being tested, the existing setup will not take off. A seamless transition will require running of two systems in parallel for some time.
If there is an exposure to the public in the authentication system for the company, the same will need to be tested properly as once it goes into public, any flaws will be exposed and will increase the vulnerability of the entire system.
Result
            Each of the implementation tests needs to be carefully conducted and all the loopholes are to be logged. The testers must be aware that the test cases should be documented as expected and achieved results. If there are deviations, the development team must be apprised of it so that system could be made foolproof at the organization level.
Discussion

Iaas is a robust cloud computing model which gives a lot of control and capabilities for implementation. Even though the a company's requirements can be met with other models, the IaaS shall be the preferred one looking at the position and significance of information with the the company.

Saturday, November 4, 2017

Structured Authoring and XML

The field of Technical Writing has evolved over the years. Documentation has become one of the main quality checks with a software or engineering products. Now, when technical writing has become that important, many tools got written or evolved over the years.

One of the main reasons why this evolvement was done was that content was always growing in volumes and besides the maintenance imbroglio, the constant repetition of content was also becoming tedious to manage.

Thus, people began to think about structured authoring where topic-based authoring is done and each topic is stored as a separate entity. A separate entity can be used wherever needed.

Introduction to Structured Authoring

Structured authoring and XML are generally an integral part of content creation today. Together they create a new paradigm of content authoring in which each part of the document is free and yet glued to a document.

Basically, Structured Authoring is nothing but an arrangement of topics in a structured way which when put together makes good sense. Since these topics are freely arranged in an XML file, they can be referenced from any other document. Thus you write them once and use them wherever you like.

The metadata and content reuse are some of the main reasons why businesses are opting for Structured Authoring. In early days, XML writing was difficult as one had to write code to keep the content in shape but today, most of the Structured Authoring tools are developed with WYSIWYG concept.

What is Structured Authoring

Structured Authoring is a way to enforce rules to maintain consistency. When multiple people work in a team, their writing style and formatting preferences are different. One would be a fan of Calibri font while the other could be in love with Arial. Now, when documents roll out of an organization, they cannot have different style and font for that matter. This is why Structured Authoring is implemented in which styles are set with DTD (Data Type Definition) so the writer will only focus on writing while the Structured Authoring Tool will use the DTD and produce output in a format, defined in the DTD.

Please watch this space for more details on Structured Authoring.

Reach out to us for technical writing services at editor.crispcontent@gmail.in.

Photo via Visualhunt.com

Wednesday, October 18, 2017

Microsoft Manual of Style

The Microsoft Manual of Style is a reference guide for technical writers, technical editors, and content managers. Primarily the Microsoft Manual of Style is written and used to write content pertaining to Microsoft products but this guide is so well written and easy to grasp, it has been adopted by a large number of companies as a technical writing standard guide. Microsoft Manual of Style (Microsoft Manual of Style) presents a detailed guide to clear definitions and concepts with screenshots. The MSTP has been released in several versions since its first release in the year 1995. The latest Microsoft Manual of Style edition is the fourth edition according to Wikipedia. The last version was published in the year 2012.

The Microsoft Manual of Style sets standards for all the writers so that everyone writes the content in the same way. The content written without following the MSTP is not incorrect but it's just not Microsoft Style. And now, since MSTP is used and referenced by many organizations to keep the tone and usage of terms in sync with each other, it is being accepted as a general standard.

For a technical writer, the knowledge of Microsoft Manual of Style standards is always a plus point. If you are aware of MSTP, you know a lot about consistency and many technical writing principles. The knowledge of MSTP becomes all the more important when we know that most of the computers are loaded with Windows Operating Systems and then applications are generally written to be run on Microsoft Personal Computers and devices.

Some organizations use their in-house style guides but if you are aware of Microsoft Manual of Style, you would be knowing most of the style guides without even seeing them. The popularity of the MSTP is one of the main reasons why technical writers prefer MSTP over other style guides developed and maintained by other publishers.

Tuesday, October 17, 2017

Technical Writing

Technical writing is all about being very specific about the topic. A Technical Writer must have total clarity about the product they are writing. this is why the field of technical writing needs skills like testing the product, interviewing the Subject Matter Experts, and knowledge of technical writing principles.

Service Level Agreement for Cloud Computing setup

SLA for Cloud Computing Service Provider As a standard practice,  the customer and service provider enters into a service based agree...