Lepaya

lepaya

Have you ever wandered into the realm of GitHub API authentication? In case you did, you have arrived in the right spot, because I have an experience that I want to share with you. When trying to authenticate to the GitHub REST API you need to use either a personal access token , the workflow GITHUB_TOKEN variable or a GitHub installation access token. The first option is not really an option for automation purpose, because a personal access token as the name suggests it is usually attributed to an user and expires after a given time frame. The GITHUB_TOKEN variable can be an interesting option for a stand-alone repo, but it is scoped to the respective repository. Hence the correct option from a GitHub organization perspective is the use of GitHub installation access token. The process of generating an installation access token requires several inputs that we obtain when we register a new GitHub application in an organization: Enter name, description, provide an URL (we’ll only use the app for authentication purposes, so you can use a dummy one) and uncheck the “Active” tick for the webhook. The other optional fields are to be left blank.
While on the same page you need to configure the permissions required by the app.
Once the registration is done, you will receive additional information on the next screen, such as app id.
While on the same screen, press “Generate a new client secret” button.
Import the App's private key in your AWS Account KMS service, under customer-managed keys of type asymmetric, sign-verify, RSA 2048, following steps 1 to 4 from the link. The private key is the client secret from previous step. The previous step follows the security best practices of storing the app private key. Storing the private key in a GitHub secret is not as secure, because if an attacker gains access to the GitHub runner environment, the attacker will consequently have access to the GitHub secret. The solution proposed is similar to Azure Key Vault, but uses AWS KMS instead. Once imported in KMS, the private key can no longer be retrieved. The authorized users can ask the AWS KMS API to sign/verify messages on their behalf, but will not perform such actions directly on the messages using the key. This way, sign/verify actions, key storage as well as user authentication and authorization are delegated to AWS. Please, make sure your AWS account access is properly secured! As you might have realized already, AWS authentication becomes the weakest link in the chain in this scenario. While AWS takes care of the security of the cloud, you are responsible for the security in the cloud. This is a broader topic which is outside the scope of this article, but as a guideline, It is highly advised to use temporary AWS credentials scoped to the least privilege when accessing AWS API in order to sign the JWT token. More on how to set up a GitHub as an OIDC provider for AWS here. Using AWS KMS will generate additional charges in your AWS bill. In the following steps, we’ll prepare the repository to be able to get the GitHub app installation access token: Store the App's ID generated previously in your repository environment variable or secret (example: APP_ID).
Store the previously generated KMS Key ID as a repository secret (example KMS_KEY_ID).
Store the AWS role to be assumed by the action as a repository secret (example ROLE_TO_ASSUME). The setup assumes you are assuming an AWS role, hence using temporary AWS credentials.
Store the AWS session name as an environment variable (example ROLE_SESSION_NAME). This is needed in case you are assuming and AWS role using OIDC.
Store the AWS region name as an environment variable (example AWS_REGION). Once you’re set up with all the above, you have all the prerequisite necessary in order to use this GitHub action for generating the GitHub installation access token for your GitHub app. The action which I have developed unlike the vanilla one uses AWS KMS in order to sign/verify the JWT token required for generating the GitHub installation access token. Terraform - A Case Study Recently I have started to investigate ways to authenticate terraform provider to the GitHub API in order to be able to use it in deploying GitHub Infrastructure (create repos, etc) inside a GitHub organization. The terraform documentation gives 2 options,  GitHub app and OAuth/personal access token. I have taken the inputs required by the GitHub app authentication (i.e. app id and app private key) and developed a GitHub action capable of using AWS KMS for storing the private key and generating the installation access token. Once the token is generated, you can override the GITHUB_TOKEN workflow environment variable with the token produced by the action. Here is a terraform example on how to use the action as well as the respective workflow file. Enjoy! Have you ever wandered into the realm of GitHub API authentication? In case you did, you have arrived in the right spot, because I have an experience that I want to share with you. When trying to authenticate to the GitHub REST API you need to use either a personal access token , the workflow GITHUB_TOKEN variable or a GitHub installation access token. The first option is not really an option for automation purpose, because a personal access token as the name suggests it is usually attributed to an user and expires after a given time frame. The GITHUB_TOKEN variable can be an interesting option for a stand-alone repo, but it is scoped to the respective repository. Hence the correct option from a GitHub organization perspective is the use of GitHub installation access token . authenticate to the GitHub REST API GITHUB_TOKEN GitHub installation access token The process of generating an installation access token requires several inputs that we obtain when we register a new GitHub application in an organization: generating an installation access token new GitHub application Enter name, description, provide an URL (we’ll only use the app for authentication purposes, so you can use a dummy one) and uncheck the “Active” tick for the webhook. The other optional fields are to be left blank. While on the same page you need to configure the permissions required by the app. Once the registration is done, you will receive additional information on the next screen, such as app id. While on the same screen, press “Generate a new client secret” button. Import the App's private key in your AWS Account KMS service, under customer-managed keys of type asymmetric, sign-verify, RSA 2048, following steps 1 to 4 from the link. The private key is the client secret from previous step. Enter name, description, provide an URL (we’ll only use the app for authentication purposes, so you can use a dummy one) and uncheck the “Active” tick for the webhook. The other optional fields are to be left blank. While on the same page you need to configure the permissions required by the app. Once the registration is done, you will receive additional information on the next screen, such as app id. While on the same screen, press “Generate a new client secret” button. Import the App's private key in your AWS Account KMS service, under customer-managed keys of type asymmetric, sign-verify, RSA 2048 , following steps 1 to 4 from the link. The private key is the client secret from previous step. Import the App's private key in your AWS Account KMS service, under customer-managed keys of type asymmetric, sign-verify, RSA 2048 Import the App's private key in your AWS Account KMS service, under customer-managed keys of type asymmetric, sign-verify, RSA 2048 The previous step follows the security best practices of storing the app private key. Storing the private key in a GitHub secret is not as secure, because if an attacker gains access to the GitHub runner environment, the attacker will consequently have access to the GitHub secret. The solution proposed is similar to Azure Key Vault, but uses AWS KMS instead. Once imported in KMS, the private key can no longer be retrieved. The authorized users can ask the AWS KMS API to sign/verify messages on their behalf, but will not perform such actions directly on the messages using the key. This way, sign/verify actions, key storage as well as user authentication and authorization are delegated to AWS. the security best practices Please, make sure your AWS account access is properly secured! Please, make sure your AWS account access is properly secured! As you might have realized already, AWS authentication becomes the weakest link in the chain in this scenario. While AWS takes care of the security of the cloud, you are responsible for the security in the cloud . This is a broader topic which is outside the scope of this article, but as a guideline, It is highly advised to use temporary AWS credentials scoped to the least privilege when accessing AWS API in order to sign the JWT token. More on how to set up a GitHub as an OIDC provider for AWS here . While AWS takes care of the security of the cloud, you are responsible for the security in the cloud here Using AWS KMS will generate additional charges in your AWS bill. Using AWS KMS will generate additional charges in your AWS bill. In the following steps, we’ll prepare the repository to be able to get the GitHub app installation access token: Store the App's ID generated previously in your repository environment variable or secret (example: APP_ID). Store the previously generated KMS Key ID as a repository secret (example KMS_KEY_ID). Store the AWS role to be assumed by the action as a repository secret (example ROLE_TO_ASSUME). The setup assumes you are assuming an AWS role, hence using temporary AWS credentials. Store the AWS session name as an environment variable (example ROLE_SESSION_NAME). This is needed in case you are assuming and AWS role using OIDC. Store the AWS region name as an environment variable (example AWS_REGION). Store the App's ID generated previously in your repository environment variable or secret (example: APP_ID ). Store the App's ID generated previously in your repository environment variable Store the App's ID generated previously in your repository environment variable secret secret APP_ID Store the previously generated KMS Key ID as a repository secret (example KMS_KEY_ID ). Store the previously generated KMS Key ID as a repository secret Store the previously generated KMS Key ID as a repository secret KMS_KEY_ID Store the AWS role to be assumed by the action as a repository secret (example ROLE_TO_ASSUME ). The setup assumes you are assuming an AWS role, hence using temporary AWS credentials . Store the AWS role to be assumed by the action as a repository secret Store the AWS role to be assumed by the action as a repository secret ROLE_TO_ASSUME temporary AWS credentials Store the AWS session name as an environment variable (example ROLE_SESSION_NAME ). This is needed in case you are assuming and AWS role using OIDC. Store the AWS session name as an environment variable Store the AWS session name as an environment variable ROLE_SESSION_NAME Store the AWS region name as an environment variable (example AWS_REGION ). Store the AWS region name as an environment variable Store the AWS region name as an environment variable AWS_REGION Once you’re set up with all the above, you have all the prerequisite necessary in order to use this GitHub action for generating the GitHub installation access token for your GitHub app. The action which I have developed unlike the vanilla one uses AWS KMS in order to sign/verify the JWT token required for generating the GitHub installation access token. this Terraform - A Case Study Recently I have started to investigate ways to authenticate terraform provider to the GitHub API in order to be able to use it in deploying GitHub Infrastructure (create repos, etc) inside a GitHub organization. The terraform documentation gives 2 options,  GitHub app and OAuth/personal access token. authenticate terraform provider I have taken the inputs required by the GitHub app authentication (i.e. app id and app private key) and developed a GitHub action capable of using AWS KMS for storing the private key and generating the installation access token. GitHub action Once the token is generated, you can override the GITHUB_TOKEN workflow environment variable with the token produced by the action. Here is a terraform example on how to use the action as well as the respective workflow file . Here workflow file Enjoy!

Access GitHub API Securely Using GitHub Actions from an Organization Perspective - A Case Study

Funding is a crucial component of your business as an entrepreneur. It is the engine that keeps your company operating and expanding. A vital phase of any startup's journey is . However, finding capital can be challenging, particularly for first-time business owners. finding funding Understanding the investment landscape is crucial whether you're a first-time entrepreneur with a game-changing idea or a seasoned founder trying to scale your organization. I'll provide pointers and advice in this comprehensive guide to help you navigate the startup fundraising process effectively. Introduction Entrepreneurs can create and introduce novel goods and services thanks to capital. The financial resources entrepreneurs need to launch and expand their enterprises are called startup finance. Entrepreneurs, angel investors, crowd funders, venture capitalists, and bootstrapping are just a few startup funding types available. is a crucial component of startup finance. Equity is the portion of a corporation investors receive in return for their investment. Since equity financing does not need repayment of funds, unlike debt financing, it is a common type of fundraising for businesses. Equity Types of Startup Funding There are several types of startup funding, including: 1- Bootstrapping Bootstrapping is the term for self-financing a firm with cash from the business or personal savings. Bootstrapping is an excellent choice for business owners who wish to keep control of their companies and avoid debt repayment stress. 2- Crowdfunding Crowdfunding is getting money from many people, generally via Internet platforms. Entrepreneurs that wish to gauge consumer demand for their goods or services might consider crowdfunding. 3. Angel financiers Wealthy people who spend money on startups in exchange for stock are known as angel investors. Angel investors assist entrepreneurs in expanding their firms by providing cash and mentoring. 4. Investors in venture capital Professional investors, known as venture capitalists, finance startups in return for stock. Venture capitalists frequently invest in high-growth firms with the potential to yield significant returns on their funds. Understanding the Funding Process Understanding the funding process is critical to navigating startup funding successfully. The funding process typically involves the following stages: 1-	Seed Funding Entrepreneurs raise money at the seed fundraising phase of the startup funding process to develop their goods or services. Crowdfunding, angel investors, and close friends and relations typically provide seed money. Series A Funding The first significant round of financing venture capitalists provide businesses is called series A funding. Series A fundraising often aims to grow the team and scale the firm. Series B Funding The second round of venture capitalist startup funding is called series B funding. Series B finance is frequently employed to quicken market expansion and growth. Series C Funding The third round of venture capitalist funding for entrepreneurs is known as Series C funding. Series C finance is frequently used to boost corporate growth and prepare for an IPO or acquisition. Preparing for Funding Preparing for funding is critical to successfully navigating startup funding. Here are some tips to help you prepare for funding: Develop a Business Plan Refining your business plan is a crucial step in preparing for funding. A well-defined business plan is a comprehensive document outlining your business concept, target market, competitive advantage, and growth strategy. When refining your business plan, focus on the following key areas: Clearly outline your value proposition and how it assists your target audience in solving an issue. Conduct in-depth market research to determine your target market's demands, trends, and potential size. Create a solid revenue strategy that spells out how you'll make money and turn a profit. Emphasize your competitive advantage by displaying your differentiators and unique selling characteristics. Outline your comprehensive marketing and sales plan, including how you'll attract and keep customers. Prepare a financial forecast considering vital financial metrics, income statements, and cash flow estimates. To make your business plan simple to grasp for investors, make sure it is concise, organized, and visually appealing. Build a Strong Team When applying for funding, it is essential to assemble a solid team. Look for people whose qualifications and experience match those of your startup. To create a collaborative work environment, define clear roles and encourage open communication. Look for mentors and advisors who can offer direction and business knowledge. Place a high value on cultural fit to create a cohesive team. Your team members should receive professional development funding and advancement chances. Offer competitive pay and a supportive work environment to keep top personnel. A powerful team indicates your capacity to carry out the business plan and respond to difficulties successfully. Create a Prototype To secure funding, a prototype must be produced. A prototype shows off the functionality and potential of your product or service in a tangible way. It offers proof of concept and makes your proposition more believable to potential investors. A prototype also enables incremental improvement, allowing you to get input and make the required changes before applying for funding. A well-designed prototype shows your execution skills and confirms your market research. It gives potential investors more faith in your business by demonstrating that you are working on a real product. By giving investors a clear picture of the value of your product and its potential market impact, a prototype increases your chances of obtaining finance. Pitching Your Startup to Investors One of the most important steps in obtaining money is to pitch investors to your firm. An effective pitch conveys your company's concept, market potential, and potential for expansion. To get the attention of potential investors, begin with a strong and concise introduction. Explain in detail how your unique value offer meets a market requirement. Highlight your competitive edge and your target market's size and growth potential. To show your business's profitability and scalability, highlight its income streams and financial projections. Show proof of progress and milestones, such as client acquisition, alliances, or product development. Stress your team's experience and track record. Finish with a direct request that details the funding amount and its intended use. To be assured and convincing, practice and polish your pitch. Always remember to customize your pitch to each investor, emphasizing the elements that fit their investment requirements and areas of interest. Develop a Compelling Pitch Create a pitch that concisely summarises your company's objectives, market analysis, special selling points, and projected financials. Your pitch needs to be succinct and exciting to get investors' attention. Understand Your Market Investigate the investment preferences and portfolios of your target investors. By adjusting your pitch to your audience's interests, you can improve your chances of obtaining money. Practice makes perfect. Practice your pitch to improve your delivery, and ensure you can confidently and effectively convey your idea. Tips for Securing Startup Funding Securing startup funding can be challenging, but here are some tips to increase your chances of success: Build Relationships with Investors Building relationships with investors might boost your chances of obtaining finance by allowing you to create credibility and trust. Networking Networking can help you connect with possible investors and build enduring relationships within the startup ecosystem. Put Traction First Investors are more inclined to fund firms with a successful track record. Concentrate on gaining traction and proving market demand to improve your prospects of getting finance. Mistakes to Avoid When Seeking Funding Avoiding common mistakes can help you navigate startup funding successfully. Here are some mistakes to avoid: Lack of Planning Your prospects of obtaining funds may suffer if you don't sufficiently prepare for the funding process. Before requesting funds, ensure you have a strong business plan, team, and prototype. Excessive Startup Value A startup's overvaluation may turn away potential investors. Make sure that the valuation of your startup is reasonable and founded on market information. Too Much Emphasis on Funding Spending too much time on financing can keep you from developing a profitable company. Keep in mind that money is a tool, not an end in and of itself. Alternative Funding Sources There are several alternative funding sources that entrepreneurs can explore, including: Grants Grants are non-repayable sums that business owners can use to launch or expand their operations. Governmental bodies, charities, and nonprofit organizations frequently award grants. Accelerators and Incubators Accelerators and incubators assist companies to expand their businesses by giving them resources, cash, and mentorship. Startups are often accepted into incubators and accelerators' programs for a set amount of time. Financed based on revenues Using revenue-based finance, entrepreneurs can access capital in exchange for a portion of their potential future earnings. Equity and Valuation Navigation To properly negotiate startup funding, you must successfully handle equity and valuation. Here are some pointers to help you understand valuation and equity: Understand Equity Structures Understanding equity structures can help you negotiate favorable terms and avoid diluting your ownership percentage. Market research to be done By conducting market research, you may estimate a reasonable valuation for your startup based on market data. Be Willing to Negotiate You may build positive relationships with investors and get to a mutually beneficial arrangement by being open to negotiation. Post-Funding Considerations After securing funding, there are several post-funding considerations that entrepreneurs should keep in mind, including: Market Relations The success of your startup depends on keeping good contacts with investors. Update investors on your company's development and answer any issues they may have.
Scaling Your Staff Growing your business requires scaling your staff. Employ people with the expertise and experience needed for your business plan. In charge of cash flow Maintaining your business's cash flow is essential for its survival. Create a financial strategy that accounts for your funding and running costs. Conclusion: Sustaining Your Startup Beyond Funding To sum up, managing startup money is crucial to your company's success. You may improve your chances of obtaining startup capital by comprehending the funding procedure, planning for funding, and avoiding typical blunders. Remember that finance is a means to a goal; to sustain your firm once it has received funding, you need a great business plan, a capable staff, and successful execution.

Startup Funding 101: Navigating the Investment Landscape

Indian Currency and Finance: Chapter VIII - The Indian Rate of Discount 

Indian Currency and Finance: Chapter VII - Indian Banking

Being GDPR compliant means having robust Data Governance in place. And robust Data Governance is built on metadata and semantics. GDPR is portrayed as somewhat of a boogeyman. Most of the talk on GDPR has been focusing on cost, rather than benefits. Yes, fines occurring as a consequence of failure to comply with GDPR can be substantial. And yes, becoming GDPR compliant incurs costs to organizations. But if GDPR did not exist, it would be necessary to invent it. It may be hard to see this now, with organizations scrambling for the final stretch of what has been a frantic race to compliance. But this race extends beyond the finish line. And that’s not just because, according to surveys, a significant part of organizations will not be GDPR-compliant on May the 25th. To be GDPR compliant is to have a robust Data Governance process and infrastructure in place. This is what enables organizations to be in control of the data they manage. If this is in place, GDPR compliance can be built on top of it. Identifying data lineage and use across the organization are typical examples of this. But there are far too many organizations in which data is managed in a haphazard fashion. Why? Lack of know-how, tools, or budget / time are some typical reasons. Just think of the average user’s personal computer storage, multiply this at organizational scale, and you get the picture. Still, it all comes down to priorities, as the race to GDPR compliance goes to show. Data Governance should have been there all along, and GDPR is a good opportunity to repay the Data Governance debt. is a term used to describe what happens in software development when choosing an easy solution now instead of using a better approach that would take longer. Over time, technical debt accumulates, until it gets to the point where it becomes really hard or even impossible to resolve / repay. Technical debt The same concept applies to Data Governance too. As many organizations have accumulated mass amounts of Data Governance debt, GDPR is the equivalent of a creditor making that debt repayable immediately. Let’s take a look at some fundamentals that can save organizations from going bankrupt: metadata and semantics. Metadata for Data Governance When we talk about Data Governance, what we really talk about is the ability to keep track of data, to be able to know things such as: What is that data about? What are the entities referenced in that data? Where is the data coming from? When were they acquired, and how? Who is using them, and where? Without being able to answer those questions, there’s no such thing as Data Governance, and no policy can possibly be enforced. What all of that really is, is data about data, or metadata. Depending on the point of view, . metadata can be classified according to different taxonomies According to , metadata can be classified as Administrative, Descriptive, Preservation, Technical, and Use metadata. Getty’s classification is among the most complete ones, as it stems from the cultural heritage world, one of professional asset and content managers. Getty’s classification Each type of metadata helps keep track of a different aspect of data. Image: Ontotext Organizations such as museums and libraries have been on the forefront of metadata research, development and use, as the need to manage assets has always been integral for them. With the proliferation of Big Data however, the average organization today may very well have more assets to manage than the average museum a few years back. Increasingly, the physical world has come to be represented in the digital realm. In addition, many processes and functions today have become primarily, or exclusively, digital. So although the types of assets and data most organizations have to manage are typically different than museums or libraries, they could benefit from their approach to using metadata. Traditionally, metadata use in the cultural heritage domain has been focused on manual annotation. That approach won’t scale for most organizations, but it does not have to be that way. Much of the metadata capturing process can be automated, achieving greater efficiency. But there’s something about the cultural heritage approach to metadata everyone could reuse. Semantics for Metadata When we talk about metadata, what we really talk about is the ability to capture and manage additional data about data. The most common form of metadata is a schema. A schema describes the structure and meaning of a dataset, thus specifying its semantics. The advent of technologies such as NoSQL stores or Hadoop, and the proliferation of unstructured or semi-structured data such as documents and multimedia has brought the use of schema under critique. But while schema-free, or schema-on-read approaches, have their merits, eventually even their proponents have come to terms the realities of data management. It can be argued that schema-free and schema-on-read are another form of data debt. As most data have structure and relationships, not dealing with them upfront can speed up storage and use, but it will eventually creep up to hinder data (re)usability. The structure and semantics in data is useful even for machine learning approaches. In similar fashion, semantics is also useful for metadata. Having well-defined, curated, and shared vocabularies to describe various types of metadata pays off. By using such vocabularies, organizations have a better picture of what the meaning of their metadata is. Semantics help define the meaning of metadata. Image: Sung-Kook Han They benefit from the accumulated experience that has gone into designing them. They avoid reinventing the wheel, and they can achieve interoperability and cross-linking among datasets, both internal and external. Some examples of such metadata vocabularies are Dublin Core, DCAT and SKOS. They all come from the Semantic Web world, and have years of modeling expertise and use in projects behind them. They also work in tandem, showcasing how semantics-powered vocabularies enable users to mix and match, customize and extend them to suit their needs. Ironically, while the Semantic Web itself has gotten a rather bad name in terms of approachability and applicability, its grand vision seems closer than ever: going from a web of documents, to a web of data. A big part of the web is already powered by Semantic Web vocabularies, most prominently schema.org. And the use of knowledge graphs and semantic data lakes is getting more widespread too. But how could a metadata, semantics-powered solution for Data Governance work in the real world? A Metadata, Semantics — powered Data Governance solution Here’s a roadmap of sorts: Build a comprehensive internal data model Use vocabularies such as Dublin Core, DCAT and SKOS to capture and manage metadata Expand to add more concrete / domain-specific models to make it easier for tools of different types to use the metadata. If that sounds interesting, but too abstract or hard, you’ll be glad to know it’s already under way in the Apache Atlas project. Atlas is a Data Governance and metadata framework for Hadoop, and has been around for a while. Now however Atlas has gotten a new life: there is a team of around 20 people in total working on it, it has support from IBM and Hortonworks, and it is . taking the center stage at one of the most important big data events in the world Atlas is based on that recipe above. If you’re interested in the technical details, you can check the , or the . Having done that, we turned to IBM Distinguished Engineer Mandy Chessel who is among Atlas’ masterminds to discuss further. Chessel explains that: in-depth presentation given at Dataworks EMEA Atlas project wiki “Many data standards have a more limited scope than what we need to describe and govern data. We have built out a comprehensive metadata type system that gives us the base metamodel for the metadata repository and the metadata exchange protocols (the Open Metadata Repository Service). This was seeded by stitching details of open standards and adding in other metadata elements that we know are needed for many client engagements. The plan is to tag our model with mappings to the open standards we have used. We are also working with on building an O-DEF tag library for metadata to tie down the semantics of the elements in our metamodel. The Open Group This is very low-level and uses concepts like entity, relationship, classification and attribute. You could think of the objects it exchanges as metadata atoms. The domain specific models/APIs are like metadata molecules. They describe larger, domain specific objects like assets, data base table, policy etc”. When discussing what lead them to use this approach, Chessel says it was “partly to show how the open standards have been combined so we can verify the open metadata model is compatible with the open standards used by different communities. But the real practical reason for maintaining the mapping to these standards is to enable metadata exchange with tools that use these standards. In particular, many open data sites use the dcat standard. It would be good to be able to exchange and consume metadata from these sites”. Above and beyond GDPR, and Hadoop That’s all fine and well in the (linked) open data world, but what about beyond that? Chessel acknowledges there has been limited uptake of open standards in commercial governance products, and says this is partly due to gaps in the standards and a lack of pressure from customers. She adds however that there is a lot of interesting work around library systems and similar content management systems that they can learn from. Plus, there are metadata standards associated with different types of data, such as photographs or location data: “the standards can capture deep expertise which is helpful in validating what we are doing”. Chessel says that designing, implementing and documenting this is done, at least as part 1 is concerned. The OMRS is practically complete and the Open Metadata Access Services are in progress. There are some pieces of the puzzle that are not quite there yet, such as lineage for which they want to step back and evaluate their options. When discussing more concrete, domain-specific models, Chessel notes that there is no metadata standard for describing a data model: “Regulators and industry consortia end up resorting to commercial products (eg ERWIN or Power designer) or spreadsheets to distribute glossaries and data models. We have interest from a regulator to build out the area 5 model to be able to capture data models and reference data so they can publish their regulations in an open format that is directly consumable by tools”. from Inside open metadata — the deep dive DataWorks Summit But what the target audience for Atlas and its real-life adoption? “Atlas is the open source project that is where we are developing the source code — this includes the APIs, frameworks, protocol implementations that are packaged together. There is also an “Atlas Server” which is a graph based metadata repository that is delivered by the Apache Atlas project too. This Atlas Server is part of the Hortonworks HDP product — which is where the Hadoop association comes from. The open metadata libraries are designed to be embedded in the Atlas server of course, but also other vendor products. Also the Atlas server runs outside of Hadoop. So we are not tied to Hadoop. Then we have developers from our products taking the open metadata libraries and incorporating them into our products. There is another large vendor looking at integration and others waiting in the wings for us to finish the domain-specific interfaces before starting their integration work. The technology we have built uses a connector framework to allow it to run on different platforms. However, adoption is key. This is where the comes from. It aims to help vendors with adoption and brings practitioners together to develop open metadata content”. ODPi Connected Data — Bringing it all together Even though Atlas is not the only solution in this space, and needs to work in a broader context including tools and processes, this is important. Atlas may be the lever for metadata and semantics to get a head start in Data Governance in the enterprise, similar to what schema.org has done for data on the web. Even though additional analysis is warranted, in the end, it’s all about connecting data. This is exactly what we’ll be doing at in London this November. If that got your attention, there’s more where that came from. We are putting together a program featuring la creme de la creme in: Connected Data Enterprise Knowledge Graphs & Schema Management Linked Data & Semantic Publishing AI, Machine Learning & Graphs Graph Databases ! Come join us while it’s still early Originally published at connected-data.london on May 21, 2018.

Stories, News & Mentions about LEPAYA

Lepaya’s Stories on HackerNoon